MySQL Bugs: #37078: falcon_bug_26828 fails sometimes on Pushbuild

Bug #37078	falcon_bug_26828 fails sometimes on Pushbuild
Submitted:	29 May 2008 20:56	Modified:	9 Oct 2008 12:55
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0-falcon bk	OS:	Any
Assigned to:	Hakan Küçükyılmaz	CPU Architecture:	Any

Description:
falcon_bug_26828 fails sometimes on Pushbuild

How to repeat:
See Pushbuild results for mysql-6.0-falcon tree.

falcon.falcon_bug_26828        [ fail ]

mysqltest: At line 45: query 'CALL p1()' failed: 1020: Record has changed since last read in table 't1'

This test starts two concurrent transactions, each of which
updates records in a partitioned table.   Both transactions
update the same records.   The transactions appear to run
in repeatable read isolation mode with consistent read.  In
that mode, this test will sometimes produce conflicting updates
and errors.

Running the test with consistent read off may elminate the
errors.

Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Failure can be easily reproduced when running test several times like:

./mysql-test-run.pl --force --mem --skip-ndb --suite=falcon falcon_bug_26828 falcon_bug_26828 falcon_bug_26828 ..., falcon_bug_26828

falcon.falcon_bug_26828        [ pass ]             11
falcon.falcon_bug_26828        [ fail ]

mysqltest: At line 45: query 'CALL p1()' failed: 1020: Record has changed since last read in table 't1'

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47868

2700 Hakan Kuecuekyilmaz	2008-06-14
      Fixed test case falcon_bug_26828.test. This fixes Bug#37078.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47870

2700 Hakan Kuecuekyilmaz	2008-06-14
      Fixed test case falcon_bug_26828.test. This fixes Bug#37078.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47871

2700 Hakan Kuecuekyilmaz	2008-06-14
      Fixed test case falcon_bug_26828.test. This fixes Bug#37078.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47872

2700 Hakan Kuecuekyilmaz	2008-06-14
      Fixed test case falcon_bug_26828.test. This fixes Bug#37078.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/47873

2700 Hakan Kuecuekyilmaz	2008-06-14
      Fixed test case falcon_bug_26828.test. This fixes Bug#37078.

Hakan's fix has been pushed to mysql-6.0-falcon and seems to resolve this issue.
I ran the test 100 times in a row with and without the fix on a Linux host. It failed 5/100 times without the fix and 0/100 times with the fix.
Test reviewed, looks fine.

Sorry about the canned answer.  Yes, I think this is a problem with the
test.  I suggest trying it in either read committed mode or better in
repeatable read with consistent read off.  Both those should (I think)
run the test without reporting update conflicts.  The unreported 
conflicts still exist and the transaction consistency isn't great, but
the goal is to get the test to run.

This fix is in version 6.0.6

Per comments from Ann and others: Test case only; no user-facing changes; closed without further action.