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: | 407d949e1002250541w6f8d50f4sceeda9640c53313f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2010-02-25 14:04:17 | psql with GSS can crash |
Previous Message | Magnus Hagander | 2010-02-25 13:27:21 | Re: Recent vendor SSL renegotiation patches break PostgreSQL |