Re: max_standby_delay considered harmful
Greg Stark <gsstark@mit.edu>
From: Greg Stark <gsstark@mit.edu>
To: Bruce Momjian <bruce@momjian.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, Robert Haas <robertmhaas@gmail.com>, 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-10T16:44:44Z
Lists: pgsql-hackers
On Mon, May 10, 2010 at 5:20 PM, Bruce Momjian <bruce@momjian.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