On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> That said, there's a few small things that can be progressed regardless of
> the details of synchronous replication. There's the changes to trigger
> failover with a signal, and it seems that we'll need some libpq changes to
> allow acknowledgments to be sent back to the master regardless of the rest
> of the design. We can discuss those in separate threads in parallel.
At first, we should fix the problem that startup process cannot
respond to SIGTERM and SIGHUP immediately by committing the patch
that I submitted in the following post.
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00858.php
> 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.
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00797.php
This makes sense. The remaining problem is which signal we should send
to postmaster. SIGHUP, SIGTERM, SIGINT, SIGQUIT and SIGUSR1 are already
used for other purposes. SIGUSR2 is actually unused, but reserved for
children according to the source code comment.
We can use SIGHUP to wake up startup process since postmaster sends
it to startup process when it arrives. But the reload of the
configuration files happens as a side-effect. So I think that SIGHUP
handler should check whether the default trigger file exists first,
and then skip the reload and just wake up startup process if it does.
Thought?
Or we should track the pid of startup process and make pg_ctl send the
signal directly to startup process?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center