Horton

Re: [HACKERS] parallel.c oblivion of worker-startup failures

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-01-24T09:57:27Z
Lists: pgsql-hackers

Attachments

On Wed, Jan 24, 2018 at 5:25 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> If there were some way for the postmaster to cause reason
> PROCSIG_PARALLEL_MESSAGE to be set in the leader process instead of
> just notification via kill(SIGUSR1) when it fails to fork a parallel
> worker, we'd get (1) for free in any latch/CFI loop code.  But I
> understand that we can't do that by project edict.

Based on the above observation, here is a terrible idea you'll all
hate.  It is pessimistic and expensive: it thinks that every latch
wake might be the postmaster telling us it's failed to fork() a
parallel worker, until we've seen a sign of life on every worker's
error queue.  Untested illustration code only.  This is the only way
I've come up with to discover fork failure in any latch/CFI loop (ie
without requiring client code to explicitly try to read either error
or tuple queues).

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

Commits

  1. Report an ERROR if a parallel worker fails to start properly.

  2. Report failure to start a background worker.