Horton

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-11T08:10:14Z
Lists: pgsql-hackers 
On 11/07/18 04:16, Thomas Munro wrote:
> On Tue, Jul 10, 2018 at 11:39 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> I don't have a FreeBSD machine at hand, so I didn't try fixing that
>> patch.
> 
> I updated the FreeBSD version to use the header test approach you
> showed, and pushed that too.  FWIW the build farm has some FreeBSD
> animals with and without PROC_PDEATHSIG_CTL.

Thanks!

> I suppose it's possibly that we might want to reconsider the choice of
> signal in the future (SIGINFO or SIGPWR).

We could reuse SIGUSR1 for this. If we set the flag in SIGUSR1 handler, 
then some PostmasterIsAlive() calls would take the slow path 
unnecessarily, but it would probably be OK. The slow path isn't that 
slow. But using SIGINFO/SIGPWR seems fine.

- Heikki

Commits

  1. Poll postmaster less frequently in recovery.

  2. Use signals for postmaster death on FreeBSD.

  3. Use signals for postmaster death on Linux.

  4. Introduce a pipe between postmaster and each backend, which can be used to