Обсуждение: Re: postmaster.pid

---

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

 

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

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

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

Andrew Dunstan <andrew@dunslane.net> 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