Missed check for too-many-children in bgworker spawning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Missed check for too-many-children in bgworker spawning
Date: 2019-10-06 17:17:37
Message-ID: 18733.1570382257@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Over in [1] we have a report of a postmaster shutdown that seems to
have occurred because some client logic was overaggressively spawning
connection requests, causing the postmaster's child-process arrays to
be temporarily full, and then some parallel query tried to launch a
new bgworker process. The postmaster's bgworker-spawning logic lacks
any check for the arrays being full, so when AssignPostmasterChildSlot
failed to find a free slot, kaboom!

The attached proposed patch fixes this by making bgworker spawning
include a canAcceptConnections() test. That's perhaps overkill, since
we really just need to check the CountChildren() total; but I judged
that going through that function and having it decide what to test or
not test was a better design than duplicating the CountChildren() test
elsewhere.

I'd first imagined also replacing the one-size-fits-all check

if (CountChildren(BACKEND_TYPE_ALL) >= MaxLivePostmasterChildren())
result = CAC_TOOMANY;

with something like

switch (backend_type)
{
case BACKEND_TYPE_NORMAL:
if (CountChildren(backend_type) >= 2 * MaxConnections)
result = CAC_TOOMANY;
break;
case BACKEND_TYPE_AUTOVAC:
if (CountChildren(backend_type) >= 2 * autovacuum_max_workers)
result = CAC_TOOMANY;
break;
...
}

so as to subdivide the pool of child-process slots and prevent client
requests from consuming slots meant for background processes. But on
closer examination that's not really worth the trouble, because this
pool is already considerably bigger than MaxBackends; so even if we
prevented a failure here we could still have bgworker startup failure
later on when it tries to acquire a PGPROC.

Barring objections, I'll apply and back-patch this soon.

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CADCf-WNZk_9680Q0YjfBzuiR0Oe8LzvDs2Ts3_tq6Tv1e8raQQ%40mail.gmail.com

Attachment Content-Type Size
check-for-enough-child-slots-for-new-bgworkers.patch text/x-diff 3.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2019-10-06 19:08:39 v12 and pg_restore -f-
Previous Message Matheus de Oliveira 2019-10-06 16:06:54 Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT