Date: Mon, 16 Mar 2020 17:30:40 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>,
	Thomas Munro <tmunro@postgresql.org>,
	pgsql-committers <pgsql-committers@lists.postgresql.org>
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Message-ID: <20200316203040.GA4019@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+hUKGKhAxJ8V8RVwCo6zJaeVrdOG1kFBHGZOOjf6DzW_omeMA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Mar-17, Thomas Munro wrote:

> Reproduced here.  The problem seems to be that macOS's getppid()
> returns the debugger's PID, while the debugger is attached.  This
> doesn't happen on FreeBSD (even though the debugger does internally
> become the parent, getppid() is careful to return the "real" parent
> PID so that user space doesn't notice this trickery; apparently Apple
> made a different choice).

Wow ...  Yeah, that was a known problem with FreeBSD, see
https://postgr.es/m/1292851036-sup-5399@alvh.no-ip.org
Evidently FreeBSD must have fixed it, but macOS has not caught up with
that ...

> The getppid() check is there to close a vanishingly rare race
> condition: when creating a WaitEventSet, we ask the kernel to tell us
> when the postmaster exits, but there is a possibility that the
> postmaster has already exited; normally that causes an error with
> errno == ESRCH (no such PID, it's already gone), but another unrelated
> process might have started that has the same PID, so we check if our
> ppid has changed after a successful return code.  That's not going to
> work under a debugger on this OS.

Irk.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services