Re: Assertion failure in walreceiver

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Assertion failure in walreceiver
Дата
Msg-id 407d949e1002250541w6f8d50f4sceeda9640c53313f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Assertion failure in walreceiver  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Assertion failure in walreceiver  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
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.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Следующее
От: Rémi Zara
Дата:
Сообщение: Re: NaN/Inf fix for ECPG