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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 32/64-bit transaction IDs?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 32/64-bit transaction IDs?