From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | pg_ctl failover Re: Latches, signals, and waiting |
Date: | 2011-01-12 15:14:56 |
Message-ID: | AANLkTi=fzuufWCAQvedGRMWKFdaBp12QDYCFnzmiL=J5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 15, 2010 at 11:14 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 15/09/10 16:55, Tom Lane wrote:
>>
>> So I'm wondering if we couldn't eliminate the five-second sleep
>> requirement here too. It's problematic anyhow, since somebody looking
>> for energy efficiency will still feel it's too short, while somebody
>> concerned about fast failover will feel it's too long.
>
> Yep.
>
>> Could the
>> standby triggering protocol be modified so that it involves sending a
>> signal, not just creating a file?
>
> Seems reasonable, at least if we still provide an option for more frequent
> polling and no need to send signal.
>
>> (One issue is that it's not clear what that'd translate to on Windows.)
>
> 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.
Comments? Objections?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
pg_ctl_failover_v1.patch | application/octet-stream | 10.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-01-12 15:15:24 | Re: Allowing multiple concurrent base backups |
Previous Message | Robert Haas | 2011-01-12 15:14:11 | Re: Add support for logging the current role |