Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date
Msg-id 4BAB1AC1.7000900@enterprisedb.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Next
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL