Skip site navigation (1) Skip section navigation (2)

Re: New trigger option of pg_standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New trigger option of pg_standby
Date: 2009-04-01 02:01:49
Message-ID: 3f0b79eb0903311901h70520cc8u9c0f1d8f4193923b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

On Fri, Mar 27, 2009 at 11:36 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Fri, 2009-03-27 at 10:25 -0400, Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> > Simon Riggs wrote:
>> >> 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.
>>
>> > -m smart|fast|immediate :-)
>>
>> +1 for using a "-m something" type of syntax instead of having to try to
>> pick single-letter switches that are mnemonic for the different cases.
>> But -1 to those particular mode names --- I think it will invite
>> confusion with pg_ctl's behavior.
>
> The choice is between
>
> * one parameter with the option being given as text within trigger file
>
> * two parameters naming different types of trigger file
>
> I don't mind which, as long as it is one of those two, unless there is a
> third way to specify things so that user has control at failover time. A
> single -m option would hardcode that decision ahead of time, which is
> undesirable behaviour, hence the additional complexity being discussed.

Thanks for the clarification.

I'd like to choose the former because it's more flexible when new
trigger action is added to pg_standby in the future. And, as Gurjeet
says, it's more friendly to do smart failover (end recovery after all
the available WAL are applied) when an empty trigger file exists.
I'll change the patch as above. Comments?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-04-01 02:32:39
Subject: Re: More message encoding woes
Previous:From: Andreas 'ads' ScherbaumDate: 2009-03-31 22:11:19
Subject: Small patch removing the "crypt" auth from sample pg_hba.conf

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group