Re: 32/64-bit transaction IDs?
| От | Ed L. | 
|---|---|
| Тема | Re: 32/64-bit transaction IDs? | 
| Дата | |
| Msg-id | 200303221027.21738.pgsql@bluepolka.net обсуждение исходный текст | 
| Ответ на | Re: 32/64-bit transaction IDs? (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | Re: 32/64-bit transaction IDs? | 
| Список | 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 по дате отправления: