Zdenek Kotala wrote:
Dne 2.03.09 08:59, Heikki Linnakangas napsal(a):
Fujii Masao wrote:
On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> wrote:
I'm leaning towards option 3, but I wonder if anyone sees a better
solution.
4. Use the shared memory to tell the startup process about the
shutdown state.
When a shutdown signal arrives, postmaster sets the corresponding
shutdown
state to the shared memory before signaling to the child processes.
The startup
process check the shutdown state whenever executing system(), and
determine
how to exit according to that state. This solution doesn't change any
existing
behavior of pg_standby. What is your opinion?
That would only solve the problem for pg_standby. Other programs you
might use as a restore_command or archive_command like "cp" or "rsync"
would still core dump on the SIGQUIT.
I think that we could have two methods. Extended method will use share
memory to say what child should do and standard which send appropriate
signal to child. For example pg_ctl could use extended communication to
better postmaster controlling.
The problem isn't in the signaling between external tools like pg_ctl
and postmaster, but the signaling between postmaster and the child
processes.
Signal multiplexing would help by releasing some signals, but to kill a
child process that can be executing an external command with system(3),
we'd still want to use a signal that does the right thing for external
commands, per usual Unix semantics. Also, the archiver process currently
detaches itself from shared memory at start, so using shared memory
doesn't seem like an improvement.
--
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
