Re: Assertion failure in walreceiver

Fujii Masao wrote:
> And we need to remove the following code from XLogSend(). This code is
> useless now since the initial CopyData message is guaranteed to arrive
> at the primary before doing XLogSend().
>
>> /*
>> * Invalid position means that we have not yet received the initial
>> * CopyData message from the slave that indicates where to start the
>> * streaming.
>> */
>> if (sentPtr.xlogid == 0 &&
>> sentPtr.xrecoff == 0)
>> return true;

Yeah, good catch.

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.

> I have one question. Do we support starting an archive recovery and
> standby server from a cold backup (not a base backup taken by online
> backup)? Though I think they would work and be very useful, I'm not
> sure they are safe.

I don't see why not. We support that in PITR, streaming replication is
just another way of getting the logs to the server.

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