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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(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-17 16:17:22
Message-ID: AANLkTincWez=H8Gm_CQL7XVQg1hJ588vePu2EwLYO2v_@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Thu, Mar 17, 2011 at 2:47 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Mar 16, 2011 at 11:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Fujii Masao <masao(dot)fujii(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-17 17:12:31
Subject: pgsql: Fix various possible problems with synchronous replication.
Previous:From: Kevin GrittnerDate: 2011-03-17 15:49:49
Subject: Re: I am confused after reading codes of PostgreSQL three week

pgsql-committers by date

Next:From: Robert HaasDate: 2011-03-17 17:12:31
Subject: pgsql: Fix various possible problems with synchronous replication.
Previous:From: Fujii MasaoDate: 2011-03-17 06:47:18
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,

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