On Sat, Mar 12, 2011 at 1:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Mar 11, 2011 at 9:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Fujii Masao <masao.fu...@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?

> 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?

Regards,

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to