| From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-general(at)postgresql(dot)org, Steven Singer <ssinger(at)navtechinc(dot)com> |
| Subject: | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit |
| Date: | 2003-04-11 15:46:55 |
| Message-ID: | 200304110946.55282.pgsql@bluepolka.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Friday April 11 2003 5:48, Jan Wieck wrote:
> Tom Lane wrote:
> > "Ed L." <pgsql(at)bluepolka(dot)net> writes:
> > > I don't think so. Can you imagine a replication queue big enough to
> > > that someone might not want to process it entirely in one
> > > transaction?
> >
> > No, I can't. The bigger the queue is, the further behind you are, and
> > the more you need to catch up; twiddling your thumbs for awhile gets
> > progressively less attractive.
>
> That is absolutely sure in an asynchronous multi-master situation, where
> "twiddling" only leads to conflicts ... not making your situation any
> easier.
>
> But in a pure master slave situation? There I can imagine this.
The context of my question is strictly master slave.
> What I cannot imagine is why one would want to try to make batches any
> other size than the original transaction. Committing smaller "chunks" of
> the masters transactions at the slave side would allow a client there to
> see an inconsistent snapshot - that is bad (tm). Committing bigger
> groups contains the risk that the slave run's out of resources that the
> master didn't need - not any better.
To what slave resources are you referring?
Ed
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ed L. | 2003-04-11 16:00:13 | Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?) |
| Previous Message | Jan Wieck | 2003-04-11 15:33:50 | Re: conditional constraints |