On Fri, Apr 11, 2003 at 07:32:15PM -0600, Ed L. wrote:
> I appreciate your pointing that out. It is pretty undesirable for data to
> appear on the slave in an order different from the one in which it appears
> on the master. I guess that's another downside to batching. I'm not sure
> this approach can do any better than approximating the order since there is
> no knowledge of the commit order.
I know this will probably require more work than you'd like, but it
seems like it might be very useful/important for the replication queue
to have definitive information about when commits occur.
BTW, I don't know how this would apply to pgsql, but both DB2 and Oracle
handle replication via the transaction logs. AFAICT they don't keep
seperate replication tables or anything; they just ship whole
transaction logs off to the slaves (a bit of a simplification, but my
point is that all the data the slaves get is in the form of the
transaction logs that are normally kept by the master anyway).
--
Jim C. Nasby (aka Decibel!) jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
