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

From Michael Paquier
Subject Re: Excessive PostmasterIsAlive calls slow down WAL redo
Date
Msg-id 20180424073740.GB15322@paquier.xyz
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 Sat, Apr 21, 2018 at 12:25:27PM +1200, Thomas Munro wrote:
> Here's a new version, because FreeBSD's new interface changed slightly.

I have been looking at the proposed set for Linux, and the numbers are
here.  By replaying 1GB worth of WAL after a pgbench run with the data
folder on a tmpfs the recovery time goes from 33s to 28s, so that's a
nice gain.

Do you have numbers with FreeBSD?  I get that this would be more
difficult to set up without a GA release perhaps...

I can also see the difference in profiles by looking for
HandleStartupProcInterrupts which gets close 10% of the attention when
unpatched, and down to 0.1% when patched.

@@ -2484,6 +2484,8 @@ ClosePostmasterPorts(bool am_syslogger)
     if (bonjour_sdref)
         close(DNSServiceRefSockFD(bonjour_sdref));
 #endif
+
+    PostmasterDeathInit();

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?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: "could not reattach to shared memory" on buildfarm member dory
Next
From: Pierre Ducroquet
Date:
Subject: [RFC] Add an until-0 loop in psql