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 по дате отправления: