MySQL Bugs: #41850: Falcon reports 0 rows in table under concurrent workload

Bug #41850	Falcon reports 0 rows in table under concurrent workload
Submitted:	4 Jan 2009 17:24	Modified:	15 May 2009 13:39
Reporter:	Philip Stoev	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S1 (Critical)
Version:	6.0-falcon-team	OS:	Any
Assigned to:	Olav Sandstå	CPU Architecture:	Any
Tags:	F_ISOLATION, pb2, pushbuild, test failure

Description:
When executing a concurrent workload in 34 threads or more with zero-sum transactions, a concurrently-running SELECT statement will report that the table contains zero rows, even though there are actually thousands of rows and no SQL statements that could cause the table to become empty.

The other Falcon consistency bugs previously reported caused individual table rows to become missing or pop up before being commited, whereas this bug is about the table being reported as completely empty.

How to repeat:
A test case will be uploaded shortly.

Grammar file for bug 41850

Attachment: bug41850.yy (application/octet-stream, text), 1.47 KiB.

To reproduce this bug, please pull from the mysql-test-extra-6.0 tree and then execute:

$ cd mysql-test/gentest
$ perl runall.pl \
  --threads=32 \
  --queries=1000000 \
  --duration=300 \
  --basedir=/build/bzr/6.0-falcon-team \
  --engine=Falcon \
  --grammar=conf/bug41850.yy \
  --gendata=conf/transactions.zz \
  --validator=DatabaseConsistency \
  --mysqld=--loose-falcon-lock-wait-timeout=1 \
  --mysqld=--log-output=none \
  --mem

This will output lines like

# 20:11:49 Bad average for table: table10_falcon_int_autoinc; average1: ; average2: ; count: 0;

which mean that a query of the form:

SELECT AVG(`int_key`) + AVG(`int`) AS average1, (SUM(`int_key`) + SUM(`int`)) / COUNT(*) AS average2, COUNT(*) AS count FROM `table10_falcon_int_autoinc`;

returned 0 rows, even though the table contains over 1000 records.

Errors like # 20:11:51 Bad average for table: table10_falcon_int_autoinc; average1: 200.0205; average2: 200.0205; count: 1461;

that is, with COUNT(*) != 0, are caused by other Falcon bugs which have been filed separately.

Philip reported that this problem cannot be repeated after the changes to create a
TransactionState object and the addition of the CycleManager to protect doomed records until after all temporary stack pointers to them have gone away.

Fix is in 6.0.11

A note have been added to the 6.0.11 changelog: 

The Falcon CycleManager has been updated, which addresses a number of issues when examining records in various transaction states and their visisbility/isolation in relation to other threads.