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(-)
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 |