Re: Assertion failure in walreceiver

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Assertion failure in walreceiver
Дата
Msg-id 4B87DC21.6040202@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Assertion failure in walreceiver  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Assertion failure in walreceiver
Следующее
От: Gokulakannan Somasundaram
Дата:
Сообщение: Re: A thought on Index Organized Tables