Bug #34560 Falcon: Chilled records are committed
Submitted: 14 Feb 2008 18:46 Modified: 10 Nov 2008 18:37
Reporter: Christopher Powers Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S2 (Serious)
Version: OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[14 Feb 2008 18:46] Christopher Powers
Description:
To free record cache memory, pending records may be "chilled" to the serial log and "thawed" back into the record cache when needed. If a transaction savepoint that contains chilled records is rolled back, the chilled records are still committed into the database.

How to repeat:
This script inserts a few records, sets a savepoint, then forces several chill operations by inserting many more records. The transaction is rolled back to the savepoint and then committed.

After the commit, only those records inserted before the savepoint appear in the table--as expected--because record cache is correct. After a restart, however, records that were chilled after the savepoint appear instead.
 
To reproduce, run the following script then immediately shutdown and restart the engine. Before shutdown, note there are 4 records with 'aaaaa...', as expected. After the restart, note there are 4 records with 'bbbbb...'.

Configuration parameters:

falcon_record_memory_max = 500m   # allow for many records in cache
falcon_record_chill_threshold = 1 # transaction >= 1MB triggers a chill
falcon_debug_mask = 8191          # view chill/thaw messages
console                           # view chill/thaw messages

CREATE TABLE t1 (s1 SERIAL, s2 VARCHAR(1000)) ENGINE=FALCON;

SET AUTOCOMMIT=0;

INSERT INTO t1 (s2) VALUES (REPEAT("a",1000));# 1*1000
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 2
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 4

SAVEPOINT alpha;

INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 8
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 16
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 32
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 64
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 128
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 256
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 512
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 1024*1000
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 2048*1000
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 4096
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 8192
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 16384
INSERT INTO t1 (s2) SELECT s2 FROM t1;        # 32768

UPDATE t1 SET s2 = repeat('b', 100);

ROLLBACK TO SAVEPOINT alpha;
COMMIT;
SELECT * FROM t1;  # should show only records prior to savepoint

Shutdown/restart the engine.

SELECT * FROM t1; # should show records updated after the savepoint

Suggested fix:
Records in the serial log are assumed to have been committed. Chilled records, however, are written pending a commit. There is nothing to indicate when chilled records have been rolled back, so the gopher thread moves them from the serial log into the page cache as if they were committed.

The same holds true during recovery, where records in the serial log are restored into the record cache and eventually by moved by the gopher thread into page images.

The solution is for both gopher and recovery to check records against the rolled back savepoints. For the gopher thread, the savepoint ids of rolled back savepoints that contained chilled records can be tracked within the transaction object. For recovery, chilled records must be logged with their corresponding savepoint id.

To reduce overhead in the serial log, each SRLUpdateRecords record should only contain records from a single savepoint so that the savepoint id can be written at the top of the record rather than once per record.
[14 Feb 2008 19:57] MySQL Verification Team
Thank you for the bug report. Verified as described.
[19 Apr 2008 22:12] Hakan Küçükyılmaz
Christopher in which version is the fix?
[19 May 2008 23:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[7 Oct 2008 12:10] Hakan Küçükyılmaz
Chris,

can you please check whether this bug is fixed?

Best regards,

Hakan
[8 Nov 2008 0:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[10 Nov 2008 18:37] Kevin Lewis
This problem was fixed for version 6.0.5 when a bitmap of rolled back Savepoints was added to each transaction.  But there were follow on problems with that code that were not discovered and fixed until this change for Bug#39696;

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

So for version 6.0.9, Savepoints that are rolled back are now correctly avoided by the gopher threads, even if they had been chilled.

Marking this as a duplicate of Bug#39696.