From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: 32/64-bit transaction IDs? |
Date: | 2003-03-22 17:27:21 |
Message-ID: | 200303221027.21738.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Saturday March 22 2003 9:55, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-22 17:28:24 | Re: Point in time recovery? |
Previous Message | Tom Lane | 2003-03-22 16:55:45 | Re: 32/64-bit transaction IDs? |