Re: 32/64-bit transaction IDs? - Mailing list pgsql-general

"Ed L." <pgsql@bluepolka.net> writes:
> On Saturday March 22 2003 11:29, Tom Lane wrote:
>> I think this last part is wrong.  It shouldn't be using the xid as part
>> of the ordering, only the sequence value.

> Why not?  How would you replay them on the slave in the same transaction
> groupings and order that occurred on the master?

Why not is easy:

    begin xact 1;
    update tuple X;
    ...

                    begin xact 2;
                    update tuple Y;
                    commit;

    ...
    update tuple Y;
    commit;

(Note that this is only possible in read-committed mode, else xact 1
wouldn't be allowed to update tuple Y like this.)  Here, you must
replay xact 1's update of Y after xact 2's update of Y, else you'll
get the wrong final state on the slave.  On the other hand, it really
does not matter whether you replay the tuple X update before or after
you replay xact 2, because xact 2 didn't touch tuple X.

If the existing DBmirror code is sorting as you say, then it will fail
in this scenario --- unless it always manages to execute a propagation
step in between the commits of xacts 2 and 1, which doesn't seem very
trustworthy.

What I'm envisioning is that you should just send updates in the order
of their insertion sequence numbers and *not* try to force them into
transactional grouping.  In the above scenario, depending on when
propagation runs it might send X update, Y update, second Y update
all in one batch; or it might send Y update in one batch and then X
update and second Y update in a later batch.  Both of these are legal
and consistent orderings.  The only ordering constraint is that the
second Y update must be applied second --- but that is certain as
long as we sort the contents of a batch by insertion order.  (The
pending-update report for the second Y update cannot have been made
until after xact 2 commits, because the MVCC semantics will force
xact 1 to wait for 2 to commit before it can update Y.)

Note that all of a transaction's updates will become visible in the
pending-update table simultaneously when it commits, so (as long as
you grab batches in single SELECTs, or with a serializable transaction)
there's no problems with partial transactions being applied by a batch.
A batch will contain all the updates of some specific set of
transactions, namely all those that committed since the prior batch
for that slave.  But you can't order the updates done by a batch in xid
order, they have to be applied in insertion order.

            regards, tom lane