From: | Steven Singer <ssinger(at)navtechinc(dot)com> |
---|---|
To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Date: | 2003-04-13 15:48:07 |
Message-ID: | Pine.LNX.4.33.0304131540260.24324-100000@pcNavYkfAdm1.ykf.navtechinc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 12 Apr 2003, Ed L. wrote:
> On Saturday April 12 2003 2:06, Steven Singer wrote:
>
> nothing wrong with that necessarily, unless you wanted to update the master
> bookkeeping on every new xid as well, in which case it would defeat my
> purpose in the master batch.
Why do you need to update the master after every commit on the slave? If
your storing the last seqid sent to the slave on that slave(you would have
to update this during every transaction on the slave but I don't see this
as a big deal) and you use that value as the authoratative value for
deciding what next to send to the slave.
You would have to periodically update the master to tell it that a
tranaction can be removed form the replication_queue but this can be done
periodically(every x transactions). If dbmirror goes down in between a
commit on the slave and the master being updated then the transactions
will stay on the master in the queue until dbmirror comes back up at which
point it will see from the slave that the transactions have been sent and
they don't need to be resent. Then the master can be updated so those
rows can be cleaned from the queue.
>
> Ed
>
--
Steven Singer ssinger(at)navtechinc(dot)com
Dispatch Systems Phone: 519-747-1170 ext 282
Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR
From | Date | Subject | |
---|---|---|---|
Next Message | Ed L. | 2003-04-13 16:06:35 | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Previous Message | Ben-Nes Michael | 2003-04-13 14:42:59 | Q about transactions |