Re: Assertion failure in walreceiver

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
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-26 14:35:13
Message-ID: 4B87DC21.6040202@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark wrote:
> 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.

Seems reasonable, though if you're unlucky the startup record goes into
the next WAL segment, which might not exist on the standby yet. So I
don't think you can "peek ahead" to see if the record exists, but you
could downgrade the fatal error to a warning, and refrain from opening
for read-only connections until you see the startup record.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gokulakannan Somasundaram 2010-02-26 14:38:54 Re: A thought on Index Organized Tables
Previous Message Heikki Linnakangas 2010-02-26 14:31:57 Re: Assertion failure in walreceiver