Re: pg_ctl failover Re: Latches, signals, and waiting - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_ctl failover Re: Latches, signals, and waiting
Date
Msg-id 4D2ECD46.4050307@enterprisedb.com
Whole thread Raw
In response to Re: pg_ctl failover Re: Latches, signals, and waiting  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: pg_ctl failover Re: Latches, signals, and waiting  (Robert Haas <robertmhaas@gmail.com>)
Re: pg_ctl failover Re: Latches, signals, and waiting  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 13.01.2011 04:29, Itagaki Takahiro wrote:
> On Thu, Jan 13, 2011 at 00:14, Fujii Masao<masao.fujii@gmail.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:
> - 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".

I agree that "failover" or even "switchover" is too specific. You might 
want promote a server even if you keep the old master still running, if 
you're creating a temporary copy of the master repository for testing 
purposes etc.

+1 for "promote". People unfamiliar with the replication stuff might not 
immediately understand that it's related to replication, but they 
wouldn't have any use for the option anyway. It should be clear to 
anyone who needs it.

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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SSI patch version 8
Next
From: Shigeru HANADA
Date:
Subject: Re: SQL/MED - file_fdw