Hi, On Fri, Mar 27, 2009 at 9:49 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > 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 > pg_standby. 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. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers