Re: max_standby_delay considered harmful - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: max_standby_delay considered harmful
Date
Msg-id 4BE7E24402000025000314AB@gw.wicourts.gov
Whole thread Raw
In response to Re: max_standby_delay considered harmful  (Bruce Momjian <bruce@momjian.us>)
Responses Re: max_standby_delay considered harmful
Re: max_standby_delay considered harmful
List 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


pgsql-hackers by date:

Previous
From: Mike Rylander
Date:
Subject: Re: max_standby_delay considered harmful
Next
From: Alvaro Herrera
Date:
Subject: Re: make install fails due to "/bin/mkdir: missing operand"