On 2015-03-15 20:10:49 +0000, Simon Riggs wrote: > On 15 March 2015 at 14:16, Andres Freund <and...@2ndquadrant.com> wrote: > > > Personally I think we just should change the default to 'shutdown' for > > all cases. That makes documentation and behaviour less surprising. And > > makes experimenting less dangerous, since you can just start again. > > We need to look at the specific situation, not make a generic decision. > > If hot_standby = off, we are unable to unpause, once paused. > > Changing the default doesn't alter that problem. > > We have two choices: 1) override to a sensible setting, 2) throw an error. > > (2) sounds clean at first but we must look deeper. We know that the > *only* possible other setting is 'shutdown', so it seems more user > friendly to do the thing we *know* they want (1), rather than pretend > that we don't. > > (1) is completely predictable and not at all surprising. Add a LOG > message if you wish, but don't throw an error.
Sorry, I don't buy this. If I have "recovery_target_action = 'pause'" in the config file, I want it to pause. Not do something else, just because postgres doesn't have a interface to unpause without SQL access. That makes some sense to developers, but is pretty much ununderstandable for mere mortals. Even worse, right now (after the bugfix), the behaviour is: postgresql.conf: # hot_standby = off recovery.conf: #recovery_target_action = 'pause' => promote (the downgrading is only active when explicitly configured) # hot_standby = off recovery.conf: recovery_target_action = 'pause' => shutdown (despite an explicit setting of pause) hot_standby = on recovery.conf: # recovery_target_action = 'pause' => pause hot_standby = on recovery.conf: recovery_target_action = 'pause' => pause To me that's just utterly confusing. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
