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