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 18:25:59 |
Message-ID: | 200303221125.59766.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Saturday March 22 2003 11:05, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-22 18:29:01 | Re: 32/64-bit transaction IDs? |
Previous Message | Tom Lane | 2003-03-22 18:05:13 | Re: 32/64-bit transaction IDs? |