Re: Querying myisam table metadata may corrupt the table

myisam_crash.rb
LPexportBug989055_myisam_crash.rb

Re: Querying myisam table metadata may corrupt the table
The problem is also reproducible with the MTR test case provided in the original bug report (I will paste it again here).
The behavior is different on 5.1/5.2 and 5.3 now. On 5.3 the assertion failure seems to have been fixed, although the corruption messageis still reproducible. On 5.1 and 5.2 debug versions the original assertion failure (Assertion `strcmp(share->unique_file_name,filename) || share->last_version' failed) is still observed, and there is no commit for bug #925377 in the tree history, apparently it was only pushed into 5.3.

1. MTR test case:

--connect(con1,localhost,root,,)
--perl
open( DATA, ">bug925377.txt" )

--connection default
--let $wait_timeout=10
--let $show_statement= SHOW PROCESSLIST
--let $field= State
--let $condition= = 'Repair by sorting'
--source include/wait_show_condition.inc

SHOW TABLE STATUS LIKE 'bug925377';

--connection con1
--reap
DROP TABLE bug925377;

1. End of MTR test case

Re: Querying myisam table metadata may corrupt the table
I created a bash version of the ruby reproducer, the table has fewer fields.
It reproduces the table marked as crashed error reliably (for me), using MariaDB 5.3.6, I will try it with the latest 5.3 next

#!/bin/sh

HOST=localhost
PORT=3306
USER=root
PASSWORD=
DATABASE=test
MYSQL_CLIENT=/usr/bin/mysql

function run_cmd {
$MYSQL_CLIENT --host=$HOST --user=$USER --password=$PASSWORD --database=$DATABASE --exec="$1" > /dev/null
}

function dbs_size {
for i in

do
run_cmd "SELECT table_schema , data_length , index_length FROM information_schema.TABLES WHERE table_schema='$DATABASE'"
done
}

function table_run {
IDX="$1"
run_cmd "CREATE TABLE table_$IDX (\`id\` int, PRIMARY KEY (\`id\`)) ENGINE=MyISAM CHARSET=latin1"
run_cmd "alter table table_$IDX disable keys"
run_cmd "alter table table_$IDX enable keys"
run_cmd "drop table table_$IDX"
}

function many_table_run {
for i in

do
table_run $i &
done
}

dbs_size &
many_table_run

1. produces in mysqld error log:
2. 120515 11:31:23 [ERROR] mysqld: Table './test/table_5' is marked as crashed and should be repaired
3. 120515 11:31:23 [ERROR] mysqld: Table 'table_5' is marked as crashed and should be repaired

Re: Querying myisam table metadata may corrupt the table
The bash reproducer in the comment above reproduces the table marked as crashed when using:
http://terrier.askmonty.org/archive/pack/5.3/build-2163/kvm-bintar-hardy-amd64/mariadb-5.3.7-Linux-x86_64.tar.gz
from
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-hardy-amd64/builds/1634
which is revision 3523 of ~maria-captains/maria/5.3

Re: Querying myisam table metadata may corrupt the table
I created a MTR version of the ruby and bash reproducers. I suspect it could be simplified even more:

1. MTR test case:

1. https://bugs.launchpad.net/maria/+bug/989055

--disable_warnings
let $h= 200;
while ($h)
{
eval DROP TABLE IF EXISTS t_$h;
dec $h;
}
--enable_warnings

--connect(con1,localhost,root,,)
--connect(con2,localhost,root,,)

let $i= 200;
while ($i)
{
eval CREATE TABLE t_$i ( id INT PRIMARY KEY, a VARCHAR(100), INDEX(a) ) ENGINE=MyISAM;
dec $i;
}

let $j= 200;
while ($j)
{
connection con1;
--send
eval ALTER TABLE t_$j DISABLE KEYS;
connection con2;
--send
eval SHOW TABLE STATUS LIKE 't_$j';
connection con1;
reap;
--send
eval ALTER TABLE t_$j ENABLE KEYS;
connection con1;
reap;
connection con2;
reap;
dec $j;
}
--connection default
disconnect con1;
disconnect con2;

let $k= 200;
while ($k)
{
eval SHOW TABLE STATUS LIKE 't_$k';
dec $k;
}

1. Fails because of warnings found in the error log:
2. YYMMDD HH:MM:SS [ERROR] mysqld: Table './test/t_XX' is marked as crashed and should be repaired

1. End of MTR test case

Re: Querying myisam table metadata may corrupt the table
Hi Peter,

There was an MTR test case in comment #2, does it not work for you?

Launchpad bug id: 989055

Re: Querying myisam table metadata may corrupt the table
Oops, sorry, in place of the "SHOW TABLE.." I intended to use "SELECT table_schema , data_length , index_length...", so:

< eval SHOW TABLE STATUS LIKE 't_$j';
> SELECT table_schema , data_length , index_length FROM information_schema.TABLES WHERE table_schema='test';

This fails because of the the table mark as crashed error in the mysqld err log.

The MTR test case in comment #2 works for me, in that it reproduces the problem of table marked as crashed.

Even though I suspect the bug may be the same, I wanted to try and produce a MTR test case for the 2nd reproducer
as it didn't involve "LOAD DATA ..." (or even writing any data to the tables), in the #2 comment MTR the query
running while keys are disabled/enabled is SHOW TABLE STATUS LIKE 'bug925377' while in the 2nd reproducer the query
is less specific (I imagine it ends up "opening for status").

I have not run it with a debug binary, if it is the same bug then please disregard it, thanks.

The problem was that ALTER TABLE ENABLE KEYS was not protecting against SHOW COMMANDS that opening the table.
The same goes for REPAIR and OPTIMIZE TABLE.
All of the above commands assumes (at least for MyISAM and Aria) that no one will access the storage engine handler until the repair has been done.

I am now testing a fix that should solve this issue by having SHOW commands wait for an alter table or repair to finish.

Fixed and pushed into 5.5 tree

Reopening for a moment to modify the 'Fix version' field

Since the fix was only pushed into 5.5, I removed 5.1/5.2/5.3 from 'Fix version'