Re: Missed check for too-many-children in bgworker spawning
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-11-04T17:29:50Z
Lists: pgsql-hackers
On 2019-Nov-04, Robert Haas wrote: > On Mon, Nov 4, 2019 at 10:42 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > > True, it's not a situation you especially want to be in. However, > > > I've lost count of the number of times that I've heard someone talk > > > about how their system was overstressed to the point that everything > > > else was failing, but Postgres kept chugging along. That's a good > > > reputation to have and we shouldn't just walk away from it. > > > > I agree with this point in principle. Everything else (queries, > > checkpointing) can fail, but it's critical that postmaster continues to > > run [...] > > Sure, I'm not arguing that the postmaster should blow up and die. I must have misinterpreted you, then. But then I also misinterpreted Tom, because I thought it was this stability problem that was "utter bunkum". > I was, however, arguing that if the postmaster fails to launch workers > for a parallel query due to process table exhaustion, it's OK for > *that query* to error out. That position makes sense to me. It would be nice [..ponies..] for the query to run regardless, but if it doesn't, it's not such a big deal; the query could have equally failed to run in a single process anyway. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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