Re: New trigger option of pg_standby - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: New trigger option of pg_standby
Date
Msg-id 49CB1ECA.5030507@enterprisedb.com
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao wrote:
> On Thu, Mar 26, 2009 at 12:48 AM, Guillaume Smet
> <guillaume.smet@gmail.com> wrote:
>> On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.gov> wrote:
>>> I find it hard to imagine a use case for the existing default
>>> behavior.
>> I thought a bit about it and I think it can be useful when your
>> priority is the availability of the service and you don't consider a
>> data loss that important: even if you have a lot of WALs segments to
>> replay, you may want to have your service up immediately in case of a
>> major problem.
> 
> Yes, I also think that this is likely use case.
> 
>> Keeping it is a good idea IMHO but I don't think it should be the default.
> 
> What does "the default" mean? You mean that new trigger should use
> the existing trigger option character (-t)?

The existing behavior doesn't seem very useful to me either. Assuming 
there is a use case though, we probably need to support both at the same 
time, perhaps using different trigger files. If there's a use case for 
both, conceivably someone will want to sometimes trigger the failover 
immediately and sometimes after all WAL segments have been replayed.

Whatever we do, the signaling method to trigger failover should behave 
the same.

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


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: [pgsql-www] shut down pgsql-interfaces (was Re: Function C and INOUT parameters)
Next
From: Peter Eisentraut
Date:
Subject: Re: [pgsql-www] shut down pgsql-interfaces (was Re: Function C and INOUT parameters)