max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Greg Stark on 10 May 2010 12:44 On Mon, May 10, 2010 at 5:20 PM, Bruce Momjian <bruce(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Josh Berkus on 10 May 2010 16:42 > 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. +1 As far as I can tell, the current delay *works*. It just doesn't necessarily work the way most people expect it to to work. Kind of like, hmmm, shared_buffers? Or effective_cache_size? Or effective_io_concurrency? And I still think that having this kind of a delay option will give us invaluable use feedback on how the option *should* work in 9.1, which we won't get if we don't have an option. I think we will be overhauling it for 9.1, but I don't think that overhaul will benefit from a lack of data. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 11 May 2010 01:01 On Mon, May 10, 2010 at 3:27 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > I already explained that killing the startup process first is a bad idea > for many reasons when shutdown was discussed. Can't remember who added > the new standby shutdown code recently, but it sounds like their design > was pretty poor if it didn't include shutting down properly with HS. I > hope they fix the bug they have introduced. HS was never designed to > work that way, so there is no flaw there; it certainly worked when > committed. New smart shutdown during recovery doesn't kill the startup process until all of the read only backends have gone away. So it works fine with HS. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 12 May 2010 02:50 On Tue, 2010-05-11 at 14:01 +0900, Fujii Masao wrote: > On Mon, May 10, 2010 at 3:27 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > > I already explained that killing the startup process first is a bad idea > > for many reasons when shutdown was discussed. Can't remember who added > > the new standby shutdown code recently, but it sounds like their design > > was pretty poor if it didn't include shutting down properly with HS. I > > hope they fix the bug they have introduced. HS was never designed to > > work that way, so there is no flaw there; it certainly worked when > > committed. > > New smart shutdown during recovery doesn't kill the startup process until > all of the read only backends have gone away. So it works fine with HS. Yes, I thought some more about what Robert said. HS works identically to normal running in this regard, so there's no hint of a bug or design flaw on that for either of us to worry about. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 May 2010 07:10
On Wed, May 12, 2010 at 2:50 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Tue, 2010-05-11 at 14:01 +0900, Fujii Masao wrote: >> On Mon, May 10, 2010 at 3:27 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> > I already explained that killing the startup process first is a bad idea >> > for many reasons when shutdown was discussed. Can't remember who added >> > the new standby shutdown code recently, but it sounds like their design >> > was pretty poor if it didn't include shutting down properly with HS. I >> > hope they fix the bug they have introduced. HS was never designed to >> > work that way, so there is no flaw there; it certainly worked when >> > committed. >> >> New smart shutdown during recovery doesn't kill the startup process until >> all of the read only backends have gone away. So it works fine with HS. > > Yes, I thought some more about what Robert said. HS works identically to > normal running in this regard, so there's no hint of a bug or design > flaw on that for either of us to worry about. I'm not sure what to make of this. Sometimes not shutting down doesn't sound like a feature to me. http://archives.postgresql.org/pgsql-hackers/2010-05/msg00098.php http://archives.postgresql.org/pgsql-hackers/2010-05/msg00103.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |