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

From Ed L.
Subject Re: 32/64-bit transaction IDs?
Date
Msg-id 200303221027.21738.pgsql@bluepolka.net
Whole thread Raw
In response to Re: 32/64-bit transaction IDs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 32/64-bit transaction IDs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Saturday March 22 2003 9:55, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.net> writes:
> > You didn't say, but do you think the xid is a reliable replication
> > replay ordering even though it comes at the start of the transaction?
>
> Dunno.  What requirements have you really got?

Again, the context is asyncronous trigger-based master-slave replication ala
contrib/dbmirror.  In this context, AFAICS, the primary requirement is to
queue updates, inserts, and deletes on a master db for later SQL retrieval
and subsequent serial "replay" into a slave in the "right" order.  The
master-queued tuple changes should be groupable as transactions so that any
replication can enforce all-or-none semantics on the slave, though normally
it should never hit a snag since the master and slave are initialized as
identical copies.  The queue should be ordered the "right" way for serial
replay into a slave, whatever that "right" way is in order to maintain
consistency with the master.  I assume triggers will have to be disabled
during replay on the slave to avoid time-sensitive side-effects.

DBMirror basically already does all of this, except for disabling triggers
and my uncertainty about the ordering issue.

Ed


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: 32/64-bit transaction IDs?
Next
From: Bruce Momjian
Date:
Subject: Re: Point in time recovery?