Re: postmaster.pid

Tom Lane wrote:

>Andrew Dunstan <[email protected]> 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




---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html