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=03xOCRVht677g_ARt9jRQ+vu6AunfnNBUdK3+x-E7Wyg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process  (Andres Freund <andres@anarazel.de>)
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: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.

Certainly, but I am reacting to reports via you of performance
problems coming from read(heavily_contended_fd) by saying: although we
can't avoid a syscall like Linux can in this case, we *can* avoid the
reportedly contended pipe mutex completely by reading only our own
process's kqueue.  Combined with Heikki's proposal not to check every
single time through busy loops to reduce the syscall frequency, that
might be the optimal solution until some hypothetical
prctl(PR_SET_PDEATHSIG)-feature-match patch arrives.  Just a thought.

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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: Peter Geoghegan
Date:
Subject: Re: Gotchas about pg_verify_checksums