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

From Robert Haas
Subject Re: pg_ctl failover Re: Latches, signals, and waiting
Date
Msg-id AANLkTi=xt1pxGZoXhO=U1CELKKSZB7CXPR+PYAC2PCLy@mail.gmail.com
Whole thread Raw
In response to Re: pg_ctl failover Re: Latches, signals, and waiting  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Thu, Jan 13, 2011 at 5:00 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> 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.

I agree.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: Bug in pg_dump
Next
From: Dimitri Fontaine
Date:
Subject: Re: Fixing GIN for empty/null/full-scan cases