pgsql: Check for too many postmaster children before spawning a bgworke

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Check for too many postmaster children before spawning a bgworke
Date: 2019-10-07 16:39:32
Message-ID: E1iHW2m-0004bA-58@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Check for too many postmaster children before spawning a bgworker.

The postmaster's code path for spawning a bgworker neglected to check
whether we already have the max number of live child processes. That's
a bit hard to hit, since it would necessarily be a transient condition;
but if we do, AssignPostmasterChildSlot() fails causing a postmaster
crash, as seen in a report from Bhargav Kamineni.

To fix, invoke canAcceptConnections() in the bgworker code path, as we
do in the other code paths that spawn children. Since we don't want
the same pmState tests in this case, add a child-process-type parameter
to canAcceptConnections() so that it can know what to do.

Back-patch to 9.5. In principle the same hazard exists in 9.4, but the
code is enough different that this patch wouldn't quite fix it there.
Given the tiny usage of bgworkers in that branch it doesn't seem worth
creating a variant patch for it.

Discussion: https://postgr.es/m/18733.1570382257@sss.pgh.pa.us

Branch
------
REL_12_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/7e8d0eb63fbb3bf01c9b4a68b12a10864ce53b52

Modified Files
--------------
src/backend/postmaster/postmaster.c | 46 ++++++++++++++++++++++++++-----------
1 file changed, 33 insertions(+), 13 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2019-10-07 17:57:41 Re: expressive test macros (was: Report test_atomic_ops() failures consistently, via macros)
Previous Message Peter Eisentraut 2019-10-07 14:55:29 pgsql: Remove use of deprecated Autoconf define