| Bug #14809 | Don't set DB_NOOVERWRITE when using hidden primary key | ||
|---|---|---|---|
| Submitted: | 10 Nov 2005 0:22 | Modified: | 17 Dec 2005 0:03 |
| Reporter: | Jim Winstead | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: BDB | Severity: | S3 (Non-critical) |
| Version: | 5.1 | OS: | Any (All) |
| Assigned to: | Jim Winstead | CPU Architecture: | Any |
[10 Nov 2005 0:25]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/32124
[17 Dec 2005 0:03]
Jim Winstead
Fixed in 5.1.4. No need to document the change, it's not user-visible at all, except for possibly a small performance gain.
Description: When we have a table without a user-defined primary key using the BDB storage engine, we don't need to set the DB_NOOVERWRITE flag on the key because we will always generate unique identifiers. (It is a simple mutex-protected counter.) How to repeat: Not applicable. Suggested fix: ===== sql/ha_berkeley.cc 1.159 vs edited ===== --- 1.159/sql/ha_berkeley.cc 2005-11-07 07:24:36 -08:00 +++ edited/sql/ha_berkeley.cc 2005-11-09 16:13:10 -08:00 @@ -665,7 +665,7 @@ /* Open other keys; These are part of the share structure */ key_file[primary_key]=file; - key_type[primary_key]=DB_NOOVERWRITE; + key_type[primary_key]= hidden_primary_key ? 0 : DB_NOOVERWRITE; DB **ptr=key_file; for (uint i=0, used_keys=0; i < table_share->keys ; i++, ptr++)