Fujii Masao wrote:
> On Mon, Jan 18, 2010 at 2:19 PM, Fujii Masao <masao.fu...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
