On Wed, Dec 11, 2013 at 7:47 PM, Andres Freund <
andres@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,