Fujii Masao wrote:
On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet
<guillaume.s...@gmail.com> wrote:
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs <si...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
