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

From Tom Lane
Subject Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)
Date
Msg-id 7679.1050017179@sss.pgh.pa.us
Whole thread Raw
In response to Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: Batch replication ordering (was Re: [GENERAL] 32/64-bit transaction IDs?)  ("Ed L." <pgsql@bluepolka.net>)
List pgsql-general
"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.

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


pgsql-general by date:

Previous
From: Joseph Shraibman
Date:
Subject: Re: The mail nttp gateway is still broken
Next
From: Peter Eisentraut
Date:
Subject: Re: OS/X and PL/PGSQL