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

From Heikki Linnakangas
Subject Re: Assertion failure in walreceiver
Date
Msg-id 4B87DC21.6040202@enterprisedb.com
Whole thread Raw
In response to Re: Assertion failure in walreceiver  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark wrote:
> 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.

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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Assertion failure in walreceiver
Next
From: Gokulakannan Somasundaram
Date:
Subject: Re: A thought on Index Organized Tables