Greg Stark wrote:
> On Thu, May 6, 2010 at 2:36 AM, Tom Lane <tgl@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
greg@2ndQuadrant.com www.2ndQuadrant.us