Below is the list of changes that have just been committed into a local
5.0 repository of svoj. When svoj does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
ChangeSet@stripped, 2006-11-15 16:47:34+04:00, svoj@stripped +1 -0
BUG#23526 - show table status reports incorrect values for MyISAM tables
This problem could happen when show table status get outdated copy
of TABLE object from table cache.
MyISAM updates state info when external_lock() method is called. Though
I_S does not lock a table to avoid deadlocks. If I_S opens a table which
is in a table cache it will likely get outdated state info copy.
In this case shared state copy is more recent than local copy. This problem
is fixed by reading state info directly from share not locking it.
Affects MyISAM only. No good deterministic test case for this fix.
myisam/mi_info.c@stripped, 2006-11-15 16:47:31+04:00, svoj@stripped +17 -8
Since INFORMATION_SCHEMA does not lock a table, info->state can be
far behind true values. For example if a table was taken from table
cache. In this case we use share as state info source, as it is more
recent than info->state.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: svoj
# Host: april.(none)
# Root: /home/svoj/devel/mysql/BUG23526/mysql-5.0-engines
--- 1.15/myisam/mi_info.c 2006-11-15 16:47:42 +04:00
+++ 1.16/myisam/mi_info.c 2006-11-15 16:47:42 +04:00
@@ -50,17 +50,26 @@ int mi_status(MI_INFO *info, register MI
}
if (flag & HA_STATUS_VARIABLE)
{
- x->records = info->state->records;
- x->deleted = info->state->del;
- x->delete_length = info->state->empty;
- x->data_file_length =info->state->data_file_length;
- x->index_file_length=info->state->key_file_length;
+ /*
+ Since INFORMATION_SCHEMA does not lock a table, info->state can be
+ far behind true values. For example if a table was taken from table
+ cache. In this case we use share as state info source, as it is more
+ recent than info->state.
+ */
+ MI_STATUS_INFO *state= (flag & HA_STATUS_NO_LOCK &&
+ info->lock_type == F_UNLCK) ?
+ &share->state.state : info->state;
+ x->records= state->records;
+ x->deleted= state->del;
+ x->delete_length= state->empty;
+ x->data_file_length= state->data_file_length;
+ x->index_file_length= state->key_file_length;
x->keys = share->state.header.keys;
x->check_time = share->state.check_time;
- x->mean_reclength = info->state->records ?
- (ulong) ((info->state->data_file_length-info->state->empty)/
- info->state->records) : (ulong) share->min_pack_length;
+ x->mean_reclength= x->records ?
+ (ulong) ((x->data_file_length - x->delete_length) /
+ x->records) : (ulong) share->min_pack_length;
}
if (flag & HA_STATUS_ERRKEY)
{
| Thread |
|---|
| • bk commit into 5.0 tree (svoj:1.2294) BUG#23526 | Sergey Vojtovich | 15 Nov |