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

From Simon Riggs
Subject Re: New trigger option of pg_standby
Date
Msg-id 1238064633.16568.420.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Guillaume Smet <guillaume.smet@gmail.com>)
Responses Re: New trigger option of pg_standby  (Guillaume Smet <guillaume.smet@gmail.com>)
Re: New trigger option of pg_standby  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote:
> On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> > What does "the default" mean? You mean that new trigger should use
> > the existing trigger option character (-t)?
> 
> Yes, that's my point.
> 
> I understand it seems weird to switch the options but I'm pretty sure
> a lot of persons currently using -t would be surprised by the current
> behaviour. Moreover playing all the remaining WALs before starting up
> should be the most natural option when people are looking in the help.

If the standby has fallen behind then waiting for it to catch up might
take hours to failover if it waits for all files. If you haven't been
monitoring it correctly, you have no clue. That is also a surprising
thing, so let's not jump from one surprising thing into the arms of
another.

If we go with this, I would suggest we make *neither* the default by
removing -t, and adopting two new options: something like -f == fast
failover, -p == patient failover. This then forces people to read and
understand the difference between the two behaviours so they can make an
informed choice of how they would like to act at this critical point in
time. It is justifiable because there is no single thing called a
trigger file any longer and the concept will lead to pain.

Earlier, we discussed having a single trigger file that contains an
option rather than two distinct trigger files. That design is better
because it allows the user to choose at failover time, rather than
making a binding decision at config time. That solution would be the
ideal one, IMHO, because it gives user more choice - and would allow us
to keep the -t option meaningfully. In that case the default should be
patience.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Matteo Beccati
Date:
Subject: Re: New trigger option of pg_standby
Next
From: Tatsuhito Kasahara
Date:
Subject: Re: display previous query string of idle-in-transaction