Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Marco Pfatschbacher <Marco_Pfatschbacher(at)genua(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Date: 2018-04-11 00:47:12
Message-ID: CAEepm=03xOCRVht677g_ARt9jRQ+vu6AunfnNBUdK3+x-E7Wyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 11, 2018 at 12:26 PM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-04-11 00:48:56 Re: Gotchas about pg_verify_checksums
Previous Message Peter Geoghegan 2018-04-11 00:45:29 Re: WIP: Covering + unique indexes.