Horton

Re: Missed check for too-many-children in bgworker spawning

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-04T19:09:45Z
Lists: pgsql-hackers 
Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> On 2019-10-09 12:29:18 -0400, Robert Haas wrote:
> > I would say rather that if fork() is failing on your system, you have
> > a not very stable system.
> 
> I don't think that's really true, fwiw. It's often a good idea to turn
> on strict memory overcommit accounting, and with that set, it's actually
> fairly common to see fork() fail with ENOMEM, even if there's
> practically a reasonable amount of resources. Especially with larger
> shared buffers and without huge pages, the amount of memory needed for a
> postmaster child in the worst case is not insubstantial.

I've not followed this thread very closely, but I agree with Andres here
wrt fork() failing with ENOMEM in the field and not because the system
isn't stable.

Thanks,

Stephen

Commits

  1. Check for too many postmaster children before spawning a bgworker.

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