"Ed L." wrote:
>
> On Friday April 11 2003 5:48, Jan Wieck wrote:
> > Tom Lane wrote:
> > > "Ed L." <pgsql@bluepolka.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?
Clearly a bug, but we had memory leaks that clear up at transaction end.
One of the "leaks" we still have: Constraint trigger queue.
Be sure, you don't want to find out that you have that kind of problem
by loosing slave by slave because your workload got worse ;-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
