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-03 03:42:05
Message-ID: 3f0b79eb0904022042g35b8e3cah9432ff764e721a3@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Apr 1, 2009 at 11:01 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> 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?

Here is the patch;
- Smart failover is chosen if the trigger file labeled "smart" or
an empty one exists.
- Fast failover is chosen if the trigger file labeled "fast" exists,
the signal (SIGUSR1 or SIGINT) is received or the wait timeout
happens.

If you notice anything, please feel free to comment.

Regards,

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

Attachment Content-Type Size
pgstandby_new_trigger_0403.patch text/x-patch 47.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2009-04-03 04:32:00 patch for small omission in psql \? help
Previous Message Bruce Momjian 2009-04-03 03:38:12 Re: Documentation Update: Document pg_start_backup checkpoint behavior