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

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: (view raw, whole thread or download thread mbox)
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.


In response to


pgsql-hackers by date

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

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