Re: 32/64-bit transaction IDs?
От | Ed L. |
---|---|
Тема | Re: 32/64-bit transaction IDs? |
Дата | |
Msg-id | 200303221125.59766.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 11:05, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.net> writes: > > > > Again, the context is asyncronous trigger-based master-slave > > replication ala contrib/dbmirror. > > AFAICS that technique does not need to worry about transaction ordering, > as long as updates are sent in the order they are inserted into the > pending-updates table... [snip] > > However, this may just move the problem somewhere else --- how will you > be sure that you transmit entries in the update table in the correct > order? That is my question. How it is done now in dbmirror is by including the xid and using a sequence object, essentially similar to insert into queue (xid, tuple_id, data, ...) values (GetCurrentTransactionId(), nextval('tuplesequence'), ...); Actually, dbmirror does it in a couple of steps, but I think this is the basic idea. So the queued tuple changes are groupable (and thus replayable) by xid and order of queueing. Then the slave gets them in the hopefully-correct order via select ... from queue q where q.xid is in some appropriate range order by xid asc, tuple_id asc; Ed
В списке pgsql-general по дате отправления: