Re: max_standby_delay considered harmful

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Robert Haas" <robertmhaas@gmail.com>, "Bruce Momjian" <bruce@momjian.us>
Cc: "Greg Smith" <greg@2ndquadrant.com>, "Simon Riggs" <simon@2ndquadrant.com>, "Josh Berkus" <josh@agliodbs.com>, "Andres Freund" <andres@anarazel.de>, "Dimitri Fontaine" <dfontaine@hi-media.com>, "Florian Pflug" <fgp@phlo.org>, <pgsql-hackers@postgresql.org>,"Tom Lane" <tgl@sss.pgh.pa.us>
Date: 2010-05-10T15:39:00Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
 
>> Overall I would say opinion is about evenly split between:
>> 
>> - leave it as-is
>> - make it a Boolean
>> - change it in some way but to something more expressive than a
>>   Boolean
 
I think a boolean would limit the environments in which HS would be
useful.  Personally, I think how far the replica is behind the
source is a more useful metric, even with anomalies on the
transition from idle to active; but a blocking duration would be
much better than no finer control than the boolean.  So my "instant
runoff second choice" would be for the block duration knob.
 
> time for a decision, and with no one agreeing on what to do,
> feature removal seemed like the best approach.
 
I keep wondering at the assertion that once a GUC is present
(especially a tuning GUC like this) that we're stuck with it.  I
know that's true of SQL code constructs, but postgresql.conf files? 
How about redirect_stderr, max_fsm_*, sort_mem, etc.?  This argument
seems tenuous.
 
> Suggesting we will fix it later in beta is not a solution.
 
I'm with you there, 100%
 
-Kevin