Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)

On Friday 11 Apr 2003 3:03 am, Ed L. wrote:
> On Thursday April 10 2003 5:26, Tom Lane wrote:
[snip][
> > 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.
>
> Exposing intermediate transaction states is precisely the issue and the
> reason for my original question. Your apparent presumption of the lack of
> value of querying a slave that's running significantly behind is a false
> blanket assumption. Of course it depends on the situation and the nature
> of the data. I can think of a number of past instances where some
> considerable lagtime in the data propagation was just fine, but
> inconsistency was not. If you aren't replicating to the slave and
> committing in one big all-inclusive batch, then there needs to be some care
> to commit in transaction units if you don't want to offer room for
> inconsistent views to slave clients.

Surely the batching should be happening at the "master" end? That's the only
place with the context to mark a "determinate state". Batch things as fine as
you like at that end, and just have the slave process multiple batches if it
can/wants to.

--
Richard Huxton