Fujii Masao wrote:
> On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
> <guillaume.smet@gmail.com> wrote:
>> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> I like the idea of removing -t and adding 2 new options so that people
>> are warned about the intended behavior.
>
> OK, I'll change the patch as Simon suggested; removing -t and adding
> two new options: -f = fast failover (existing behavior), -p patient failover.
> Also I'll default the patient failover, so it's performed when the signal
> (SIGINT or SIGUSR1) is received.
Uh oh, that's going to be quite tricky with signals. Remember that
pg_standby is called for each file. A trigger file persists until it's
deleted, but a signal will only be received by the pg_standby instance
that happens to be running at the time.
Makes me wonder if the trigger pg_standby with signals is reliable to
begin with. What if the backend is just processing a file when the
signal is fired, and there's no pg_standby process running at the moment
to receive it? Seems like the signaler needs to loop until it has
successfully delivered the signal to a pg_standby process, which seems
pretty ugly.
Given all the recent trouble with signals, and the fact that it's
undocumented, perhaps we should just rip out the signaling support from
pg_standby.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
