maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Sergey" == Sergey Petrunya <psergey@xxxxxxxxxxxx> 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