Re: postmaster.pid

Re: postmaster.pid

Dave Page wrote:

>  
>
>     ------------------------------------------------------------------------
>     *From:* pgsql-hackers-win32-owner@postgresql.org
>     [mailto:pgsql-hackers-win32-owner@postgresql.org] *On Behalf Of
>     *Dave Page
>     *Sent:* 20 August 2004 20:57
>     *To:* Barry Lind; pgsql-hackers-win32@postgresql.org
>     *Cc:* Max Dunn
>     *Subject:* Re: [pgsql-hackers-win32] postmaster.pid
>
>      
>      
>     I've been thinking about this problem as well, and think you might
>     just be on to something here. I'll look into this some more...
>      
>
> The correct way to do this is MoveFileEx("postmaster.pid", NULL, 
> MOVEFILE_DELAY_UNTIL_REBOOT);. This /should/ write a registry entry to 
> tell the system to delete the file at reboot. Unfortunately, it seems 
> that this is an administrator-only operation which of course means it 
> won't work when run under the postgresql service account.
>  
>

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). ISTM the correct solution would be to 
implement the effect of kill(pid,0) in port/kill.c, presumably by a call 
to some native Windows function that gives you the process info for a 
given pid.

cheers

andrew

Re: postmaster.pid

Tom Lane wrote:

>Andrew Dunstan  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

Re: postmaster.pid

Andrew Dunstan  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.  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?)

			regards, tom lane

Re: postmaster.pid

Andrew Dunstan  writes:
> Tom Lane wrote:
>> Should you not send the zero signal the same way
>> as other signals, and just let the recipient ignore it?

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

Sure, but all that we have to emulate is that there is no visible effect
on the target process.  If it receives and throws away a zero signal,
we're good.  (Especially since this isn't done often enough to be a
performance issue.)

> 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 ;-)

I think we could just return ESRCH always if we have no pipe for the
process.  The callers will actually treat these errnos the same anyway.

			regards, tom lane

Re: postmaster.pid