Re: Missed check for too-many-children in bgworker spawning
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-04T18:53:00Z
Lists: pgsql-hackers
Hi, 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. > The fact that parallel query is going to fail is sad, but not as sad > as the fact that connecting to the database is also going to fail, and > that logging into the system to try to fix the problem may well fail > as well. Well, but parallel query also has to the potential to much more quickly lead to a lot of new backends being started than you'd get new connections on an analytics DB. > Code that tries to make parallel query cope with this situation > without an error wouldn't often be tested, so it might be buggy, and > it wouldn't necessarily be a benefit if it did work. I expect many > people would rather have the query fail and free up slots in the > system process table than consume precisely all of them and then try > to execute the query at a slower-than-expected rate. I concede that you have a point here. Greetings, Andres Freund
Commits
-
Check for too many postmaster children before spawning a bgworker.
- 8c2910ce5ed7 9.5.20 landed
- c69e982a60fb 9.6.16 landed
- 7e8d0eb63fbb 12.1 landed
- 3887e9455f81 13.0 landed
- 1b5c2ddcdefc 10.11 landed
- 021065aac676 11.6 landed
-
Report an ERROR if a parallel worker fails to start properly.
- 2badb5afb89c 11.0 cited