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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_ctl failover Re: Latches, signals, and waiting
Дата
Msg-id AANLkTi=xt1pxGZoXhO=U1CELKKSZB7CXPR+PYAC2PCLy@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_ctl failover Re: Latches, signals, and waiting  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Christian Ullrich
Дата:
Сообщение: Re: Bug in pg_dump
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Fixing GIN for empty/null/full-scan cases