Greg Stark wrote:
On Thu, May 6, 2010 at 2:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
One reason I believe this isn't so critical as all that is that it only
matters for cases where the operation on the master took an exclusive
lock.
Uhm, or a vacuum ran. Or a HOT page cleanup occurred, or a btree page
split deleted old tuples.
Right; because there are so many regularly expected causes for query
cancellation, the proposed boolean setup really hurts the ability of a
server whose primary goal is high-availability to run queries of any
useful duration. For years I've been hearing "my HA standby is idle,
how can I put it to use?"; that's the back story of the users I thought
everyone knew were the known audience waiting for this feature.
If the UI for vacuum_defer_cleanup_age that prevented these things was
good, I would agree that the cases where max_standby_delay does
something useful are marginal. That's why I tried to get someone
working on SR to provide a hook for that purpose months ago. But since
the vacuum adjustment we have in completely obtuse xid units, that
leaves max_standby_delay as the only tunable here that you can even
think about in terms of human time.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
