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

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 07:22:47
Message-ID: 4D830847.6040105@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On 18.03.2011 07:13, Fujii Masao wrote:
> On Fri, Mar 18, 2011 at 1:17 AM, Robert Haas<robertmhaas(at)gmail(dot)com>  wrote:
>> 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.

If recovery target is set to before its consistent, ie. before 
minRecoveryPoint, we should throw an error before recovery even starts. 
I'm not sure if we check that at the moment.

Not sure what to to do recovery target is beyond minRecoveryPoint and 
pause_at_recovery_target=true, but the server hasn't been opened for hot 
standby yet (because it hasn't seen a running-xacts record yet). I agree 
it's pretty useless and annoying to stop there.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-03-18 07:52:07
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Fujii MasaoDate: 2011-03-18 06:25:06
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

pgsql-committers by date

Next:From: Simon RiggsDate: 2011-03-18 07:52:07
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Fujii MasaoDate: 2011-03-18 06:25:06
Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

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