On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas
> 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.
You are right!
> 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
So far, to be frank, I was not sure why the trigger by the signal is necessary
for pg_standby. But, now, I think that it's useful when the user has forgotten
to specify the trigger file. In this case, without the signaling
support, there is
no way to do failover in a short time; probably, the user has to do shutdown
and restart a recovery from the last restart point, which would take time.
So, I'd like to leave the signaling support as a safeguard.
As you pointed out, the "smart" failover by signal would be very tricky. So,
maybe we should not change the existing behavior of pg_standby when
the signal is received.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Andrew Gierth||Date: 2009-03-30 03:15:03|
|Subject: Re: TupleTableSlot API problem|
|Previous:||From: Alvaro Herrera||Date: 2009-03-30 02:01:03|
|Subject: Re: Re: [COMMITTERS] pgsql: Temporarily (I hope) disableflattening of IN/EXISTS sublinks|