Re: max_standby_delay considered harmful

Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)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.

You are right that we are much more flexible about changing
administrative configuration parameters (like this one) than SQL. In the
past, we even renamed logging parameters to be more consistent, and I
think that proves the bar is quite low for GUC administrative parameter
change. :-)

The concern about 'max_standby_delay' is that it controls a lot of new
code and affects the behavior of HS/SR in ways that might cause a poor
user experience, expecially for non-expert users. I admit that expert
users can use the setting, but we are coding for a general user base,
and we might have to field many questions about 'max_standby_delay' from
general users that will make us look bad. "The setting is total
useless" is something we have heard about other partial solutions we
have released in the past. We try to avoid that. ;-) Labeling
something "experimental" also makes our code look sloppy. And if we
decide the problem is unsolvable using this approach, we should remove
it now rather than later. We don't like to carry around a wart for a
small segment of our userbase.

I realize many of you have not been around to see some of our
less-than-perfect solutions and to see the pain they cause. Once
something gets it, we have to fight to remove it. In fact, there is no
way we would add 'max_standby_delay' into our codebase now, knowing its
limitations, but people are having to fight hard for its removal, if
necessary.

Now that discussion has restarted again, let's keep going to see if can
reach some kind of simple solution.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com