Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

On Wed, Feb 9, 2011 at 07:22, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Feb 9, 2011 at 2:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Why did you change the default to on? This would surprise people who are
>>> used to PITR.
>>
>> You pointed out that the code did not match the documented default. So I
>> made them match according to the docs.
>
> Well, I meant changing the docs rather than the code.
>
>> Making it pause at target by default is more natural behaviour, even if
>> it is a change of behaviour. It can waste a lot of time if it leaves
>> recovery at the wrong point so I don't see the change as a bad one? Only
>> PITR is affected, not replication or standalone operation.
>
> I agree that new option is useful to reduce the waste of time as you described.
> But I'm still not sure that the change of default behavior is better.

FWIW, I like the change of behavior. We obviously need to put it
prominently in the release notes, but it makes life significantly
easier.

> Because I can
> easily imagine the case where a user feels confused about the pause of PITR
> when he starts PITR as he did in previous version. It would take some time for
> him to learn what to do in that situation (i.e., execute pg_xlog_replay_resume).
>
> On the second thought, I think it's useful to emit the NOTICE message when
> recovery reaches the pause point, as follows.
>
>    NOTICE: Recovery will not complete until pg_xlog_replay_resume() is called.

Combined with this, yes.

I was also worried about the non-hot-standby case, but I see that the
patch makes sure you can't enable pause when not in hot standby mode.
Which in itself might be surprising - perhaps we need a NOTICE for
when that happens as well?

And it definitely needs to be mentioned in the docs for
pause_at_recovery_target that it only works in hot standby.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/