Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Дата
Msg-id 4BAB1AC1.7000900@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Tom Lane wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> OK. How about making the startup process emit WARNING, stop WAL replay and
>> wait for the presence of trigger file, when an invalid record is found?
>> Which keeps the server up for readonly queries. And if the trigger file is
>> found, I think that the startup process should emit a FATAL, i.e., the
>> server should exit immediately, to prevent the server from becoming the
>> primary in a half-finished state. Also to allow such a halfway failover,
>> we should provide fast failover mode as pg_standby does?
> 
> I find it extremely scary to read this sort of blue-sky design
> discussion going on now, two months after we were supposedly
> feature-frozen for 9.0.  We need to be looking for the *rock bottom
> minimum* amount of work to do to get 9.0 out the door in a usable
> state; not what would be nice to have later on.

Agreed, this is getting complicated. I'm already worried about the
amount of changes needed to make it work, I don't want to add any new
modes. PANIC seems like the appropriate solution for now.

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


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL