Re: Excessive PostmasterIsAlive calls slow down WAL redo

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-06T19:09:52Z
Lists: pgsql-hackers
Greetings,

* Heikki Linnakangas (hlinnaka@iki.fi) wrote:
> On 06/04/18 19:39, Andres Freund wrote:
> >On 2018-04-06 07:39:28 -0400, Stephen Frost wrote:
> >>While I tend to agree that it'd be nice to just make it cheaper, that
> >>doesn't seem like something that we'd be likely to back-patch and I tend
> >>to share Heikki's feelings that this is a performance regression we
> >>should be considering fixing in released versions.
> 
> To be clear, this isn't a performance *regression*. It's always been bad.

Oh, I see, apologies for the confusion, my initial read was that this
was due to some patch that had gone in previously, hence it was an
actual regression.  I suppose I tend to view performance issues as
either "regression" or "opportunity for improvement" and when you said
"bug" it made me think it was a regression. :)

> I'm not sure if I'd backpatch this. Maybe after it's been in 'master' for a
> while and we've gotten some field testing of it.

If it's not a regression then there's I definitely think the bar is much
higher to consider this something to back-patch.  I wouldn't typically
argue for back-patching a performance improvement unless it's to address
a specific regression.

Thanks!

Stephen

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