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

Re: pg_ctl failover Re: Latches, signals, and waiting

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl failover Re: Latches, signals, and waiting
Date: 2011-01-13 05:10:26
Message-ID: AANLkTimGEFdY_9zd4hFvaJSgY=D-UmiVO0c0ZKPNe9tw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 13, 2011 at 11:29 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> On Thu, Jan 13, 2011 at 00:14, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>> pg_ctl failover ? At the moment, the location of the trigger file is
>>> configurable, but if we accept a constant location like "$PGDATA/failover"
>>> pg_ctl could do the whole thing, create the file and send signal. pg_ctl on
>>> Window already knows how to send the "signal" via the named pipe signal
>>> emulation.
>>
>> The attached patch implements the above-mentioned pg_ctl failover.
>
> I have three comments:

Thanks for the review!

> - Will we call it "failover"? We will use the command also in "switchover"
>  operations. "pg_ctl promote" might be more neutral, but users might be
>  hard to imagine replication feature from "promote".

OK. Similarly, I should also change the word "failover" used in function and
variable names to the "promote"? For example,
#define PROMOTE_SIGNAL_FILE "promote" rather than
#define FAILOVER_SIGNAL_FILE "failover"?

> - pg_ctl should unlink failover_files when it failed to send failover signals.

Good catch.

> - "standby_triggered" variable might be renamed to "failover_triggered" or so.

Furthermore, "failover_triggered" should be renamed to "promote_triggered"?

Regards,

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

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-01-13 05:12:47
Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:From: Tom LaneDate: 2011-01-13 04:57:20
Subject: Re: arrays as pl/perl input arguments [PATCH]

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