From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Missed check for too-many-children in bgworker spawning |
Date: | 2019-11-04 18:53:00 |
Message-ID: | 20191104185300.na6vgywxnujclo7o@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-04 18:55:02 | Re: Wrong value in metapage of GIN INDEX. |
Previous Message | Andres Freund | 2019-11-04 18:44:53 | Re: 64 bit transaction id |