Transaction message segmenting does not work in all cases

[David Shrewsbury]

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':

BEGIN;
INSERT row #1;
UPDATE row #2
...
UPDATE row #N-1
INSERT row #N;
COMMIT;

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

[David Shrewsbury (dshrews)]

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.