#At file:///home/satya/WORK/mysql-5.0-bugteam-41330/ based on revid:patrick.crews@stripped
2775 Satya B 2009-03-17
Fix for BUG#41330 -Myisam table open count set to zero before index blocks
are written.
When we have a myisam table with DELAY_KEY_WRITE option, index updates
are not applied until the flush tables command is issued or until the
server is shutdown. If server gets killed before the index updates are
written to disk, the index file is corrupted as expected but the table
is not marked as crashed. So when we start server with myisam-recover,
table is not repaired leaving the table unusable.
The problem is when we try to write the index updates to index file,
we decrement the open_count even before the flushing the keys to index
file.
Fixed by moving the decrement operation after flushing the keys to the
index file. So we always have non zero open count if the flush table
operation is killed and when the server is started with mysiam-recover
option, it marks the table as crashed and repairs it
Note: No testcase added as we need to kill the server and start the
server with different set of options and other non trivial
operations involved.
modified:
myisam/mi_close.c
per-file messages:
myisam/mi_close.c
Fixed mi_close() to do open_count decrement after flush_key_blocks()
method.
=== modified file 'myisam/mi_close.c'
--- a/myisam/mi_close.c 2007-03-28 17:46:42 +0000
+++ b/myisam/mi_close.c 2009-03-17 13:35:20 +0000
@@ -35,8 +35,6 @@ int mi_close(register MI_INFO *info)
if (info->lock_type == F_EXTRA_LCK)
info->lock_type=F_UNLCK; /* HA_EXTRA_NO_USER_CHANGE */
- if (share->reopen == 1 && share->kfile >= 0)
- _mi_decrement_open_count(info);
if (info->lock_type != F_UNLCK)
{
@@ -68,6 +66,10 @@ int mi_close(register MI_INFO *info)
share->temporary ? FLUSH_IGNORE_CHANGED :
FLUSH_RELEASE))
error=my_errno;
+
+ if (share->kfile >= 0)
+ _mi_decrement_open_count(info);
+
if (share->kfile >= 0)
{
/*

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.