On Wed, Oct 9, 2019 at 10:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, that means we have a not-very-stable system then.
>
> We could improve on matters so far as the postmaster's child-process
> arrays are concerned, by defining separate slot "pools" for the different
> types of child processes. But I don't see much point if the code is
> not prepared to recover from a fork() failure --- and if it is, that
> would a fortiori deal with out-of-child-slots as well.
I would say rather that if fork() is failing on your system, you have
a not very stable system. 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. 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.
Anyway, here's some previous discussion on this topic for your consideration:
https://www.postgresql.org/message-id/flat/CAKJS1f_6H2Gh3QyORyRP%2BG3YB3gZiNms_8QdtO5gvitfY5N9ig%40mail.gmail.com
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company