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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(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 11:13:56
Message-ID: AANLkTi=xt1pxGZoXhO=U1CELKKSZB7CXPR+PYAC2PCLy@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 13, 2011 at 5:00 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 13.01.2011 04:29, Itagaki Takahiro 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:
>> - 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2011-01-13 11:24:18 Re: Fixing GIN for empty/null/full-scan cases
Previous Message Robert Haas 2011-01-13 11:06:08 Re: pg_primary_conninfo