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
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. |