Re: Excessive PostmasterIsAlive calls slow down WAL redo - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Excessive PostmasterIsAlive calls slow down WAL redo
Date
Msg-id CAEepm=0vT4ekDnN1p1eSqgQOc0q5oaoGoaF0QuZf_BRsEtaQpg@mail.gmail.com
Whole thread Raw
In response to Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Excessive PostmasterIsAlive calls slow down WAL redo
List pgsql-hackers
On Wed, Apr 25, 2018 at 6:23 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Apr 24, 2018 at 7:37 PM, Michael Paquier <michael@paquier.xyz> wrote:
>> Thomas, trying to understand here...  Why this place for the signal
>> initialization?  Wouldn't InitPostmasterChild() be a more logical place
>> as we'd want to have this logic caught by all other processes?
>
> Yeah, you're right.  Here's one like that.

Amazingly, due to the way the project schedules fell and thanks to the
help of a couple of very supportive FreeBSD committers and reviewers,
the new PROC_PDEATHSIG_CTL kernel facility[1] landed in a production
release today, beating the Commitfest by several days.

My question is whether this patch set is enough, or people (Andres?) want
to go further and actually kill the postmaster death pipe completely.
My kqueue patch would almost completely kill it on BSDs as it happens,
but for Linux there are a number of races and complications to plug to
do that IIUC.  I don't immediately see what there is to gain by doing
that work (assuming we reuse WaitEventSet objects in enough places),
and we'll always need to maintain the pipe code for other OSes anyway.
So I'm -0.5 on doing that, even though the technical puzzle is
appealing...

[1]
https://www.freebsd.org/cgi/man.cgi?query=procctl&apropos=0&sektion=2&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html

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


pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Typo in llvm_function_reference
Next
From: Amit Langote
Date:
Subject: Re: partitioning - changing a slot's descriptor is expensive