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.linnakangas@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