On Wed, Dec 11, 2013 at 7:47 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > I don't think that position has any merit, sorry: Think about the way > this stuff gets setup. The user creates a new basebackup (pg_basebackup, > manual pg_start/stop_backup, shutdown primary). Then he creates a > recovery conf by either starting from scratch, using > --write-recovery-conf or by copying recovery.conf.sample. In none of > these cases delay will be configured. >
Ok. > So, with that in mind, the only way it could have been configured is by > the user *explicitly* writing it into recovery.conf. And now you want to > to react to this explicit step by just *silently* ignoring the setting > based on some random criteria (arguments have been made about > hot_standby=on/off, standby_mode=on/off which aren't directly > related). Why on earth would that by a usability improvement? > > Also, you seem to assume there's no point in configuring it for any of > hot_standby=off, standby_mode=off, recovery_target=*. Why? There's > usecases for all of them: > * hot_standby=off: Makes delay useable with wal_level=archive (and thus > a lower WAL volume) > * standby_mode=off: Configurations that use tools like pg_standby and > similar simply don't need standby_mode=on. If you want to trigger > failover from within the restore_command you *cannot* set it. > * recovery_target_*: It can still make sense if you use > pause_at_recovery_target. > > In which scenarios does your restriction actually improve anything? > Given your arguments I'm forced to review my understanding of the problem. You are absolutely right in your assertions. I was not seeing the scenario on this perspective. Anyway we need to improve docs, any suggestions? Regards, -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL >> Timbira: http://www.timbira.com.br >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> Twitter: http://twitter.com/fabriziomello
