Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid
Date
Msg-id CA+hUKG+4n6XE40s0HeMscVARwPvb_aZ78tDFE6A0uTrr7ZSwKQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Weaker shmem interlock w/o postmaster.pid
List pgsql-hackers
On Mon, Apr 8, 2019 at 6:42 PM Noah Misch <noah@leadboat.com> wrote:
> - AIX animals failed two ways.  First, I missed a "use" statement such that
>   poll_start() would fail if it needed more than one attempt.  Second, I
>   assumed $pid would be gone as soon as kill(9, $pid) returned[1].

> [1] POSIX says "sig or at least one pending unblocked signal shall be
> delivered to the sending thread before kill() returns."  I doubt the
> postmaster had another signal pending often enough to explain the failures, so
> AIX probably doesn't follow POSIX in this respect.

It looks like you fixed this, but I was curious about this obversation
as someone interested in learning more about kernel stuff and
portability... Maybe I misunderstood, but isn't POSIX referring to
kill(sig, $YOUR_OWN_PID) there?  That is, if you signal *yourself*,
and no other thread exists that could handle the signal, it will be
handled by the sending thread, and in the case of SIGKILL it will
therefore never return.  But here, you were talking about a perl
script that kills the postmaster, no?  If so, that passage doesn't
seem to apply.  In any case, regardless of whether the signal handler
has run to completion when kill() returns, doesn't the pid have to
continue to exist in the process table until it is reaped by its
parent (possibly in response to SIGCHLD), with one of the wait*()
family of system calls?

-- 
Thomas Munro
https://enterprisedb.com



pgsql-hackers by date:

Previous
From: "Matsumura, Ryo"
Date:
Subject: Qestion about .partial WAL file
Next
From: David Rowley
Date:
Subject: Re: Should the docs have a warning about pg_stat_reset()?