On Wed, Oct 9, 2019 at 10:21 AM Tom Lane <t...@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
