Re: Assertion failure in walreceiver - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Assertion failure in walreceiver
Date
Msg-id 407d949e1002250541w6f8d50f4sceeda9640c53313f@mail.gmail.com
Whole thread Raw
In response to Re: Assertion failure in walreceiver  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Assertion failure in walreceiver
List pgsql-hackers
On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Committed removal of that and the assertion. You still can't use a copy
> of the data directory taken right after initdb, because the initial
> checkpoint record has the flag set indicating that archiving is not
> enabled. While we're at it, the error message doesn't seem right:
>
> FATAL:  recovery connections cannot start because the
> recovery_connections parameter is disabled on the WAL source server
>
> recovery_connections is on by default, the real problem is that
> archive_command and max_wal_senders are disabled.

Perhaps we need to put these flags in a record on startup. If they're
not set on the checkpoint you start at you check if the next record is
a shutdown and it starts up with the flags set.

I'm not sure that's exactly right as I've never looked at the wal
sequence on shutdown and startup. But it seems like a problem if you
want to start replication, find that archive_mode needs to be set so
you restart your database with it set but then still can't start up
the slave until a checkpoint happens on the master.


--
greg


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Next
From: Rémi Zara
Date:
Subject: Re: NaN/Inf fix for ECPG