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=0qJsxrY6uJ6ZqxJPpssL8xj299CpreNuZhVbmv69Zfgg@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 18, 2018 at 5:04 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Apr 11, 2018 at 10:22 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>> On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund <andres@anarazel.de>
>>> wrote:
>>>> That person said he'd work on adding an equivalent of linux'
>>>> prctl(PR_SET_PDEATHSIG) to FreeBSD.
>
> Here is an implementation of Andres's idea for Linux, and also for
> patched FreeBSD (for later if/when that lands).  Do you think this
> makes sense Heikki?  I am planning to add this to the next CF.

Here's a new version with a stupid bug fixed (I accidentally posted a
testing version that returned false instead of true, as cfbot quickly
pointed out -- d'oh).

By the way, these patches only use the death signal to make
PostmasterIsAlive() fast, for use by busy loops like recovery.  The
postmaster pipe is still used for IO/timeout loops to detect
postmaster death.  In theory you could get rid of the postmaster pipe
completely when USE_POSTMASTER_DEATH_SIGNAL is defined and make it
like the latch code, using the same self-pipe.  I'm not sure if there
is anything to be gained by that (that wasn't already gained by using
epoll/kqueue) so I'm not proposing it.

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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Postgres 10 problem with UNION ALL of null value in "subselect"
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process