Transaction message segmenting does not work in all cases

Bug #686781 reported by David Shrewsbury
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
David Shrewsbury
Fix Released
David Shrewsbury

Bug Description

Once a GPB Transaction messages reaches a certain size in bytes, we are supposed to use a new Transaction message with the same transaction ID for the continuing transaction changes. We handle this properly when we have a single statement affecting many rows, for example:

UPDATE x SET y = 10 WHERE z > 0;

This update could potentially cause many record changes which would cause the Transaction message to reach its limit. It is handled correctly.

However, the protobuf definitions don't seem to have the flexibility to be able to handle the case of many single-row-affecting statements. So the below does not segment for large values of 'N':

INSERT row #1;
UPDATE row #2
UPDATE row #N-1
INSERT row #N;

Workaround is to keep transaction sizes below the value used for --transaction-message-threshold.

Tags: replication

Related branches

Changed in drizzle:
importance: Undecided → Medium
Changed in drizzle:
status: Confirmed → In Progress
milestone: future → 2011-01-17
Revision history for this message
David Shrewsbury (dshrews) wrote :

Current plan is to add a 'segment_id' and 'end_segment' values to the Transaction GPB message format (similar to the values used in the Statement GPB message). These can be used in conjunction with the values in the Statement message.

So when a Statement needs to be segmented (which we currently support), we will set the segment information in the Statement AND Transaction messages.

When a Transaction needs to be segmented due to the situation described in the bug report (many statements, none of which are segmented themselves), then the Transaction message segment information will be used.

Changed in drizzle:
status: In Progress → Fix Committed
Changed in drizzle:
status: Fix Committed → Fix Released
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.