Re: 32/64-bit transaction IDs?

"Ed L." <pgsql@bluepolka.net> writes:
> On Saturday March 22 2003 9:55, Tom Lane wrote:
>> Dunno.  What requirements have you really got?

> Again, the context is asyncronous trigger-based master-slave replication ala
> contrib/dbmirror.

AFAICS that technique does not need to worry about transaction ordering,
as long as updates are sent in the order they are inserted into the
pending-updates table.  When two transactions update the same row, one
is going to be forced to wait till the other commits; so the waiter's
report will appear second.  For nonconflicting updates you might not
apply them in the same order they were physically made at the master,
but I can't see how it matters.

(I'm not entirely certain, but I think this works only if the reports
are made by AFTER triggers.  However, you'd have to do that anyway,
since a BEFORE trigger can't be certain it's the last BEFORE trigger.
Sending a report from a BEFORE trigger might send a report containing
a row value that's not what ultimately gets inserted, due to mods made
by later BEFORE triggers.)

However, this may just move the problem somewhere else --- how will you
be sure that you transmit entries in the update table in the correct
order?

            regards, tom lane