[Maria-developers] MyISAM locking question
Hi! I've got this test failure in maria-5.1-table-elimination tree: main.mysql-bug41486 [ fail ] http://askmonty.org/buildbot/builders/jaunty-amd64-rel/builds/54/steps/test/... CURRENT_TEST: main.mysql-bug41486 --- .../r/mysql-bug41486.result +++ .../r/mysql-bug41486.reject @@ -8,6 +8,5 @@ SET @@global.general_log = @old_general_log; SELECT LENGTH(data) FROM t1; LENGTH(data) -2097152 DROP TABLE t1; SET @@global.max_allowed_packet = @old_max_allowed_packet; mysqltest: Result length mismatch Here's the relevant part of the .test file: CREATE TABLE t1(data LONGBLOB); INSERT INTO t1 SELECT REPEAT('1', 2*1024*1024); let $outfile= $MYSQLTEST_VARDIR/tmp/bug41486.sql; --error 0,1 remove_file $outfile; --exec $MYSQL_DUMP test t1 > $outfile SET @old_general_log = @@global.general_log; SET @@global.general_log = 0; # Check that the mysql client does not insert extra newlines when loading # strings longer than client's max_allowed_packet --exec $MYSQL --max_allowed_packet=1M test < $outfile 2>&1 SET @@global.general_log = @old_general_log; SELECT LENGTH(data) FROM t1; My analysis relvealed that this part of the test INSERT INTO t1 SELECT REPEAT('1', 2*1024*1024); let $outfile= $MYSQLTEST_VARDIR/tmp/bug41486.sql; --error 0,1 remove_file $outfile; --exec $MYSQL_DUMP test t1 > $outfile gets executed as follows: when $MYSQL_DUMP runs the SELECT /*!40001 SQL_NO_CACHE */ * FROM `t1` statement to get the table data, the select produces nothing, even though INSERT statement has already finished by that time (at least from client point of view). The reason for select producing nothing is that the optimizer identifies table t1 as constant (it has one or zero rows), then it tries to get the record with handler->read_first_row() call, and it gets HA_ERR_END_OF_FILE. So far I've fixed the test case by adding SELECT COUNT(*) FROM t1 (as an arbitrary select statement involving t1) after the INSERT. The questions are: - Is the above behavior expected of MyISAM? (I suppose it is but I'm not sure) - Any ideas why does this suddenly show up when I make totally unrelated changes in table elimination code. The changed part of the code is never executed by the test... BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
Hi!
"Sergey" == Sergey Petrunya <psergey@askmonty.org> writes:
Sergey> Hi! Sergey> I've got this test failure in maria-5.1-table-elimination tree: Sergey> main.mysql-bug41486 [ fail ] <cut> Sergey> Here's the relevant part of the .test file: Sergey> CREATE TABLE t1(data LONGBLOB); Sergey> INSERT INTO t1 SELECT REPEAT('1', 2*1024*1024); Sergey> let $outfile= $MYSQLTEST_VARDIR/tmp/bug41486.sql; Sergey> --error 0,1 Sergey> remove_file $outfile; Sergey> --exec $MYSQL_DUMP test t1 > $outfile Sergey> SET @old_general_log = @@global.general_log; Sergey> SET @@global.general_log = 0; Sergey> # Check that the mysql client does not insert extra newlines when loading Sergey> # strings longer than client's max_allowed_packet Sergey> --exec $MYSQL --max_allowed_packet=1M test < $outfile 2>&1 Sergey> SET @@global.general_log = @old_general_log; Sergey> SELECT LENGTH(data) FROM t1; Sergey> My analysis relvealed that this part of the test Sergey> INSERT INTO t1 SELECT REPEAT('1', 2*1024*1024); Sergey> let $outfile= $MYSQLTEST_VARDIR/tmp/bug41486.sql; Sergey> --error 0,1 Sergey> remove_file $outfile; Sergey> --exec $MYSQL_DUMP test t1 > $outfile Sergey> gets executed as follows: when $MYSQL_DUMP runs the Sergey> SELECT /*!40001 SQL_NO_CACHE */ * FROM `t1` Sergey> statement to get the table data, the select produces nothing, even though Sergey> INSERT statement has already finished by that time (at least from client Sergey> point of view). Sergey> The reason for select producing nothing is that the optimizer identifies Sergey> table t1 as constant (it has one or zero rows), then it tries to get the Sergey> record with handler->read_first_row() call, and it gets HA_ERR_END_OF_FILE. As the insert has finished and returned to the client, the data should be there for any client to see and there should be exactly one row in the table. If you get HA_ERR_END_OF_FILE here, something is seriously wrong. Sergey> So far I've fixed the test case by adding SELECT COUNT(*) FROM t1 (as an Sergey> arbitrary select statement involving t1) after the INSERT. Sergey> The questions are: Sergey> - Is the above behavior expected of MyISAM? (I suppose it is but I'm not Sergey> sure) No. Sergey> - Any ideas why does this suddenly show up when I make totally unrelated Sergey> changes in table elimination code. The changed part of the code is never Sergey> executed by the test... Sorry no. Is this repeatable one any machine I could access ? Can you create a debug trace with mysqld with --debug when this happens? Regards, Monty
participants (2)
-
Michael Widenius -
Sergey Petrunya