Re: Assertion failure in walreceiver

From: Greg Stark <stark(at)mit(dot)edu>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assertion failure in walreceiver
Date: 2010-02-25 13:41:59
Message-ID: 407d949e1002250541w6f8d50f4sceeda9640c53313f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2010-02-25 14:04:17 psql with GSS can crash
Previous Message Magnus Hagander 2010-02-25 13:27:21 Re: Recent vendor SSL renegotiation patches break PostgreSQL