transaction log attributing statements to wrong tables on multi-table, multi-statement transactions

[Patrick Crews]

The transaction log is attributing statements to the wrong table (the first used) for multi-table, multi-statement transactions.

For this set of queries:
CREATE TABLE t1(a INT NOT NULL AUTO_INCREMENT, b INT NOT NULL, PRIMARY KEY(a), KEY b_key1 (b));
CREATE TABLE t2 LIKE t1;

START TRANSACTION;
INSERT INTO t1 (b) VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(100),(101);
INSERT INTO t2 (b) VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(100),(101);

UPDATE t1 SET b = b*10 WHERE b%2=0;
UPDATE t2 SET b = b/10 WHERE b%2=0;
COMMIT;

We get this transaction log ouput:
NOTE: Both the INSERT and UPDATE against t2 are attributed to t1.

+SELECT PRINT_TRANSACTION_MESSAGE('transaction.log',(select max(entry_offset) from DATA_DICTIONARY.TRANSACTION_LOG_TRANSACTIONS));
+PRINT_TRANSACTION_MESSAGE('transaction.log',(select max(entry_offset) from DATA_DICTIONARY.TRANSACTION_LOG_TRANSACTIONS))
+transaction_context {
+ server_id: 1
+ transaction_id: 5
+ START_TIMESTAMP
+ END_TIMESTAMP
+}
+statement {
+ type: INSERT
+ START_TIMESTAMP
+ END_TIMESTAMP
+ insert_header {
+ table_metadata {
+ schema_name: "test"
+ table_name: "t1"
+ }
+ field_metadata {
+ type: INTEGER
+ name: "a"
+ }
+ field_metadata {
+ type: INTEGER
+ name: "b"
+ }
+ }
+ insert_data {
+ segment_id: 1
+ end_segment: true
+ record {
+ insert_value: "1"
+ insert_value: "1"
+ }
+ record {
+ insert_value: "2"
+ insert_value: "2"
+ }
+ record {
+ insert_value: "3"
+ insert_value: "3"
+ }
+ record {
+ insert_value: "4"
+ insert_value: "4"
+ }
+ record {
+ insert_value: "5"
+ insert_value: "5"
+ }
+ record {
+ insert_value: "6"
+ insert_value: "6"
+ }
+ record {
+ insert_value: "7"
+ insert_value: "7"
+ }
+ record {
+ insert_value: "8"
+ insert_value: "8"
+ }
+ record {
+ insert_value: "9"
+ insert_value: "9"
+ }
+ record {
+ insert_value: "10"
+ insert_value: "10"
+ }
+ record {
+ insert_value: "11"
+ insert_value: "100"
+ }
+ record {
+ insert_value: "12"
+ insert_value: "101"
+ }
+ record {
+ insert_value: "1"
+ insert_value: "1"
+ }
+ record {
+ insert_value: "2"
+ insert_value: "2"
+ }
+ record {
+ insert_value: "3"
+ insert_value: "3"
+ }
+ record {
+ insert_value: "4"
+ insert_value: "4"
+ }
+ record {
+ insert_value: "5"
+ insert_value: "5"
+ }
+ record {
+ insert_value: "6"
+ insert_value: "6"
+ }
+ record {
+ insert_value: "7"
+ insert_value: "7"
+ }
+ record {
+ insert_value: "8"
+ insert_value: "8"
+ }
+ record {
+ insert_value: "9"
+ insert_value: "9"
+ }
+ record {
+ insert_value: "10"
+ insert_value: "10"
+ }
+ record {
+ insert_value: "11"
+ insert_value: "100"
+ }
+ record {
+ insert_value: "12"
+ insert_value: "101"
+ }
+ }
+}
+statement {
+ type: UPDATE
+ start_timestamp: 1277844822567193
+ end_timestamp: 1277844822568660
+ update_header {
+ table_metadata {
+ schema_name: "test"
+ table_name: "t1"
+ }
+ key_field_metadata {
+ type: INTEGER
+ name: "a"
+ }
+ set_field_metadata {
+ type: INTEGER
+ name: "b"
+ }
+ }
+ update_data {
+ segment_id: 1
+ end_segment: true
+ record {
+ key_value: "2"
+ after_value: "20"
+ }
+ record {
+ key_value: "4"
+ after_value: "40"
+ }
+ record {
+ key_value: "6"
+ after_value: "60"
+ }
+ record {
+ key_value: "8"
+ after_value: "80"
+ }
+ record {
+ key_value: "10"
+ after_value: "100"
+ }
+ record {
+ key_value: "11"
+ after_value: "1000"
+ }
+ record {
+ key_value: "2"
+ after_value: "0"
+ }
+ record {
+ key_value: "4"
+ after_value: "0"
+ }
+ record {
+ key_value: "6"
+ after_value: "1"
+ }
+ record {
+ key_value: "8"
+ after_value: "1"
+ }
+ record {
+ key_value: "10"
+ after_value: "1"
+ }
+ record {
+ key_value: "11"
+ after_value: "10"
+ }
+ }
+}

[Patrick Crews (patrick-crews)]

This does not appear to be the case for all multi-table, multi-statement transactions:

<snip>
...
DELETE FROM t2 WHERE b%10=0 ;
INSERT INTO t1 (b) VALUES (10),(15);
COMMIT;

For this code, the INSERT message is properly attributed to t1. It seems that if the actions (INSERT, DELETE, UPDATE) differ, that the messages will be correct.

However, something like:
INSERT INTO t1...
INSERT INTO t2...
will fail / register everything as belonging to t1.