On 2019-Oct-09, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Oct 9, 2019 at 10:21 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> 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. > > 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 -- that way, once the high load episode is over, connections can be re-established as needed, auxiliary processes can be re-launched, and the system can be again working normally. If postmaster dies, all bets are off. Also: an idle postmaster is not using any resources; on its own, killing it or it dying would not free any useful resources for the system load to be back to low again. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
