Re: max_standby_delay considered harmful

On Mon, May 10, 2010 at 5:20 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> 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 would like to propose that we do the following:

1) Replace max_standby_delay with a boolean as per heikki's suggestion

2) Add an explicitly experimental option like max_standby_delay or
recovery_conflict_timeout which is only effective if you've chosen
recovery_conflict="pause recovery"
option and is explicitly documented as being scheduled to be replaced
with a more complete system in future versions.

My thinking is that when we do replace max_standby_delay we would keep
the recovery_conflict parameter with the same semantics. It's just the
additional experimental option which would change.

--
greg