From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Steven Singer <ssinger(at)navtechinc(dot)com> |
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 16:06:35 |
Message-ID: | 200304131006.35190.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sunday April 13 2003 9:48, 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.
Agreed, I don't think you need to update the master after every commit on
the slave. On the contrary, I was simply making the observation that it
would not be useful to do so with respect to performance and traffic.
> 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.
Agreed, exactly.
Ed
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-04-13 16:32:23 | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
Previous Message | Steven Singer | 2003-04-13 15:48:07 | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |