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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: pg_ctl failover Re: Latches, signals, and waiting
Дата
Msg-id 4D2ECD46.4050307@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pg_ctl failover Re: Latches, signals, and waiting  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SSI patch version 8
Следующее
От: Shigeru HANADA
Дата:
Сообщение: Re: SQL/MED - file_fdw