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

Re: Streaming replication, and walsender during recovery

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, and walsender during recovery
Date: 2010-03-16 09:11:56
Message-ID: 4B9F4B5C.80606@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Fujii Masao wrote:
> On Mon, Jan 18, 2010 at 2:19 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> When I configured a cascaded standby (i.e, made the additional
>> standby server connect to the standby), I got the following
>> errors, and a cascaded standby didn't start replication.
>>
>>  ERROR:  timeline 0 of the primary does not match recovery target timeline 1
>>
>> I didn't care about that case so far. To avoid a confusing error
>> message, we should forbid a startup of walsender during recovery,
>> and emit a suitable message? Or support such cascade-configuration?
>> Though I don't think that the latter is difficult to be implemented,
>> ISTM it's not the time to do that now.
> 
> We got the consensus that the cascading standby feature should be
> postponed to v9.1 or later. But when we wrongly make the standby
> connect to another standby, the following confusing message is still
> output.
> 
>     FATAL:  timeline 0 of the primary does not match recovery target timeline 1
> 
> How about emitting the following message instead? Here is the patch.
> 
>     FATAL:  recovery is in progress
>     HINT:  cannot accept the standby server during recovery.

Commmitted. I edited the message and error code a bit:

ereport(FATAL,
        (errcode(ERRCODE_CANNOT_CONNECT_NOW),
         errmsg("recovery is still in progress, can't accept WAL
streaming connections")));

ERRCODE_CANNOT_CONNECT_NOW is what we use when the system is shutting
down etc, so that that seems appropriate.

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

In response to

Responses

pgsql-hackers by date

Next:From: Gokulakannan SomasundaramDate: 2010-03-16 11:49:55
Subject: Bug in 9.0Alpha4
Previous:From: Dimitri FontaineDate: 2010-03-16 09:02:07
Subject: Re: Getting to beta1

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