On Wed, 2011-03-16 at 16:29 +0900, Fujii Masao wrote:
> On Sat, Mar 12, 2011 at 1:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Fri, Mar 11, 2011 at 9:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Fujii Masao <masao.fujii@gmail.com> writes:
> >>> Yeah, since I like the former, I changed the wordings in the doc and
> >>> recovery.conf.sample. What about the attached patch?
> >>
> >> Please stop plastering the code with elog(FATAL) calls. Those are
> >> hardly ever appropriate. In contexts where it might be reasonable
> >> to do that, the error handler will treat ERROR like FATAL anyway.
> >
> > Another problem here is that we are defaulting to hot_standby=off and
> > pause_at_recovery_target=on. So AIUI, with this patch, if someone
> > sets a recovery target without making any other changes to the
> > configuration, their database won't start up. That seems poor.
>
> We should flip the default value of pause_at_recovery_target?
No, we shouldn't. Robert's comments are wrong and he shouldn't post such
things without testing them or reading the code.
> > Even without the FATAL error, this whole pause_at_recovery_target
> > thing is a little weird. If someone sets a recovery target without
> > making any other configuration changes, and Hot Standby is not
> > enabled, then we will enter normal running, but if Hot Standby *is*
> > enabled, then we'll replay to that point and pause recovery. That
> > seems a bit confusing.
>
> That's because there is no way to resume recovery which was
> paused by pause_at_recovery_target when hot standby is disabled,
> i.e., in that case we cannot call pg_xlog_replay_resume() to resume
> the recovery.
>
> How should recovery work when pause_at_recovery_target is
> enabled but hot standby is disabled? We have three choices:
>
> 1. Forbit those settings, i.e., throw FATAL error. Tom dislikes this
> idea.
> 2. Ignore pause_at_recovery_target. When recovery reaches the
> target, it ends without pausing, and then the server gets into
> normal processing mode. This would be unexpected behavior
> from DBA's point of view because he or she expects that
> recovery is paused at the target. To retry recovery, he or she
> needs to restore the backup again.
> 3. Pause recovery even if hot standby is disabled. Since there
> is no way to resume recovery, recovery would pause until
> shutdown is requested.
>
> For me, #1 looks like the most harmless in them. But, better
> ideas? Votes?
(2) is how it works now.
(3) doesn't sound very sensible. Why would that be better than (2)
There's lots of ways to misconfigure things, so I'm not too concerned
about this minor point.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
