Large row affecting statements failing mid-transaction may not get undone properly by TransactionServices if part of multi-message Transaction

Bug #683147 reported by David Shrewsbury
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Fix Released
High
David Shrewsbury
7.0
Fix Released
High
David Shrewsbury

Bug Description

This bug report is a reminder for me to investigate this further...

Say you have:

BEGIN;
UPDATE t1;
INSERT INTO t2 ... SELECT FROM t3;
COMMIT;

If all of the row changes from both statements can fit in a single GPB Transaction message, then if the INSERT..SELECT fails, we have no problem as its effects are undone properly by Transaction Services.

However, if the number of rows affected by INSERT..SELECT is large and causes the Transaction message to be split up (as for a bulk insert), then if that statement fails *after* it has been segmented, I believe we'll issue a ROLLBACK for the entire transaction, which is total fail.

Need a test case to confirm this.

Tags: replication

Related branches

Revision history for this message
Stewart Smith (stewart) wrote :

test in this branch has one for exactly this kind of situation.

Changed in drizzle:
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.