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

From Robert Haas
Subject Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Date
Msg-id AANLkTincWez=H8Gm_CQL7XVQg1hJ588vePu2EwLYO2v_@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
List pgsql-hackers
On Thu, Mar 17, 2011 at 2:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 11:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Fujii Masao <masao.fujii@gmail.com> writes:
>>> 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.
>>
>> No, I didn't say that.  I said not to write elog(FATAL).
>
> Oh, sorry.
>
>>  If the
>> combination is nonsensical then it's fine to forbid it, but you don't
>> need FATAL for that.  In particular, attempting to change to a
>> disallowed setting after system startup should not result in crashing
>> the postmaster.  And it won't, if you just use the normal error level
>> for complaining about an invalid GUC setting.
>
> 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.

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).

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: I am confused after reading codes of PostgreSQL three week
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.