On Wed, Feb 9, 2011 at 07:22, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Feb 9, 2011 at 2:02 PM, Simon Riggs <si...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers