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.
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.
> Also, AFAIR from prior discussion, the *slave* side doesn't need to
> commit the whole batch in one transaction. I can't recall if this
> could expose transaction intermediate states on the slave, but if
> you're that far behind you'd best not be having any live clients
> querying the slave anyway.
I'm not aware of any "COMMIT BUT HIDE AND RESUME;"
There are scenarios where your online processes have clear priority over
the master to multislave replication. Think of a load balanced multisite
search engine ... does it really matter that all the sites stay as sync
as possible? Do people expect Google to be up to date on a per minute
base?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
