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

"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.

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.

In any case you can throttle the load by sleeping between selects while
holding the transaction open. I think your concern is predicated on
Oracle-ish assumptions about the cost of holding open a transaction.
The only such cost in PG is that it interferes with VACUUM cleaning
out old tuples --- which I'm not sure VACUUM could do anyway for stuff
that still hasn't propagated to a slave.

regards, tom lane