Horton

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

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2011-01-13T10:00:38Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove rare corner case for data loss when triggering standby server.

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