Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>I think we're on the wrong track here. If there is a pid file then the
>>postmaster will try to see if the process is running by calling
>>kill(pid,0) - see backend/utils/init/miscinit.c.
>>
>>
>
>
>
>>However, on Windows we simulate kill(), and always return EINVAL if the
>>signal <= 0 (see port/kill.c).
>>
>>
>
>That's clearly broken.
>
we are agreed :-)
>Should you not send the zero signal the same way
>as other signals, and just let the recipient ignore it? (This assumes
>that the pre-existing postmaster is accessible to a would-be new
>postmaster's kill ... is that true?)
>
>
>
>
Umm - my Linux manpage says that no signal is actually sent in these
circumstances, just a check that we could send some other signal if we
wanted to.
The error returns are as follows:
EINVAL An invalid signal was specified.
ESRCH The pid or process group does not exist. Note that an
existing
process might be a zombie, a process which already
committed
termination, but has not yet been wait()ed for.
EPERM The process does not have permission to send the signal
to any
of the receiving processes. For a process to have
permission to
send a signal to process pid it must either have root
privi-
leges, or the real or effective user ID of the sending
process
must equal the real or saved set-user-ID of the
receiving pro-
cess. In the case of SIGCONT it suffices when the
sending and
receiving processes belong to the same session.
So Dave's patch is clearly wrong where it returns EINVAL. How we should
distinguish between the other two cases I am less sure of - IANAWP ;-)
cheers
andr4ew