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
|
Список | 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 по дате отправления: