I'm not really very cognizant of these slave/master things. I know I will have
to be someday.
but the case I heard in the conversation that seemed to most be appropriate to
batching was when a slave starts from a clean slate. It should not be able to be
accessed until it has caught up, true. But catching up a blank slave would most
definitely hammer on a master, I think.
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.
>
> 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
>
