Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Date
Msg-id CAEepm=298omvRS2C8WO=Cxp+WcM-Vn8V3x4_QhxURhKTRCSfYg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On Wed, Apr 11, 2018 at 12:47 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund <andres@anarazel.de> wrote:
>> On 2018-04-11 12:17:14 +1200, Thomas Munro wrote:
>>> I arrived at this idea via the realisation that the closest thing to
>>> prctl(PR_SET_PDEATHSIG) on BSD-family systems today is
>>> please-tell-my-kqueue-if-this-process-dies.  It so happens that my
>>> kqueue patch already uses that instead of the pipe to detect
>>> postmaster death.  The only problem is that you have to ask it, by
>>> calling it kevent().  In a busy loop like those two, where there is no
>>> other kind of waiting going on, you could do that by calling kevent()
>>> with timeout = 0 to check the queue.
>>
>> Which is not cheap.

After bouncing that idea around with a fellow pgsql-hacker off-list, I
take that idea back.  It's a lot simpler and as cheap if not cheaper
to check getppid() == 1 or similar every Nth time through the busy
loop.

I heard another interesting idea -- you can use F_SETOWN + O_ASYNC to
ask for SIGIO to be delivered to you when the pipe is closed.
Unfortunately that'd require a different pipe for each backend so
wouldn't work for us.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Fix for documentation of Covering Indexes
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Boolean partitions syntax