From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Date: | 2018-04-24 07:37:40 |
Message-ID: | 20180424073740.GB15322@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre Ducroquet | 2018-04-24 07:58:47 | [RFC] Add an until-0 loop in psql |
Previous Message | Magnus Hagander | 2018-04-24 07:18:18 | Re: "could not reattach to shared memory" on buildfarm member dory |