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:
Category:MySQL Server: Falcon storage engine Severity:S1 (Critical)
Version:6.0-falcon-team OS:Any
Assigned to: Olav Sandstå
Tags: F_ISOLATION, pb2, pushbuild, test failure
Triage: Triaged: D2 (Serious)

[4 Jan 2009 17:24] Philip Stoev
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.
[4 Jan 2009 17:47] Philip Stoev
Grammar file for bug 41850

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

[4 Jan 2009 18:14] Philip Stoev
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 \

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.
[30 Mar 2009 21:50] Kevin Lewis
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.
[17 Apr 2009 17:00] Olav Sandstå
Fix is in 6.0.11
[15 May 2009 13:39] MC Brown
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.