On Thursday March 20 2003 11:12, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > I need a guaranteed ordering of transaction IDs as they are queued for
> > asyncronous replication. I'd use the 32-bit internal transaction ID
> > from GetTransactionId(), but 32-bits will not suffice for the logic I'd
> > like to use. A 64-bit ID would work well enough.
>
> Uh ... your replication logic cannot ensure to reach closure within two
> billion transactions? Something's pretty out of joint there.
Uh...er...well... It just simplifies and robustifies a little logic if I can
do a clean-sweep delete of replicated transactions based on the xid being
less than some marker value. Something like
DELETE
FROM replication_queue
WHERE xid < (SELECT MIN(last_mirrored_xid) FROM slave);
where slave is a relation of slaves to keep track of where they are in the
replication process. When transaction IDs wrap around, that logic breaks
down for the new xids of 1, 2, 3, ... , and more accounting is required.
In our case, under considerable load, it probably wouldn't wrap for a year
or three, but it'd be nice to avoid that little timebomb it if it's easy.
> > Further, I am uncertain those 32-bit transaction IDs represent a
> > correctly ordered sequence of transactions.
>
> XIDs are issued in transaction start order, not transaction commit
> order. Dunno if that's what's concerning you.
Yes, I'm interested in any reliable ordering of transaction commits for the
purpose of serial asyncronous replication. Is that possible?
Ed
