Re: max_standby_delay considered harmful

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-06 02:48:53
Message-ID: 4BE22E15.7070301@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark wrote:
> On Thu, May 6, 2010 at 2:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-05-06 03:23:23 Re: pg_migrator to /contrib in a later 9.0 beta
Previous Message Tom Lane 2010-05-06 02:36:37 Re: pg_migrator to /contrib in a later 9.0 beta