Skip site navigation (1) Skip section navigation (2)

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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Date: 2011-03-18 05:13:13
Message-ID: AANLkTim8wzgiVfSUjK=JT58ZGngRELLJq=x7KzLkVcQo@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2011-03-18 05:45:44
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: YAMAMOTO TakashiDate: 2011-03-18 02:26:21
Subject: Re: SSI bug?

pgsql-committers by date

Next:From: Fujii MasaoDate: 2011-03-18 05:45:44
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Robert HaasDate: 2011-03-17 19:46:57
Subject: pgsql: Minor fixes for high availability documentation.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group