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

On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Sorry, I've not been able to understand the point well yet. We should
>> just use elog(ERROR) instead? But since ERROR in startup process
>> is treated as FATAL, I'm not sure whether it's worth using ERROR
>> instead. Or you meant another things?
>
> Yeah, I think he's saying that an ERROR in the startup process is
> better than a FATAL, even though the effect is the same.

We've already been using FATAL all over the recovery code. We should
s/FATAL/ERROR/g there (at least readRecoveryCommandFile)?

> On the substantive issue, I don't think we have any consensus that
> forbidding this combination of parameters is the right thing to do
> anyway.  Both Simon and I voted against that, and Tom's point has to
> do only with style.  Similarly, I voted for flipping the default for
> pause_at_recovery_target to off, rather than on, but no one else has
> bought into that suggestion either.  Unless we get some more votes in
> favor of doing one of those things, I think we should focus on the
> actual must-fix issue here, which is properly documenting the way it
> works now (i.e. adding the parameter to recovery.conf.sample with
> appropriate documentation of the current behavior).

I agree to flip the default to false, whether we forbid that combination
of settings.

> One thing I'm not quite clear on is what happens if we reach the
> recovery target before we reach consistency.  i.e. create restore
> point, flush xlog, abnormal shutdown, try to recover to named restore
> point.  Is there any possibility that we can end up paused before Hot
> Standby has actually started up.  Because that would be fairly useless
> and annoying.

Good catch! In that case, the same situation as (3) would happen.
I think that recovery should ignore pause_at_recovery_target until
it reaches consistent point. If we do so, when recovery target is
ahead of consistent point, recovery just ends in inconsistent point
and throws FATAL error.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center