Re: postmaster.pid

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