Greg Stark wrote: > On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas > <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
