On Thu, Jul 31, 2014 at 9:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Baker, Keith [OCDUS Non-J&J]" <kbak...@its.jnj.com> writes: >> Since ensuring there are not orphaned back-end processes is vital, could we >> add a check for getppid() == 1 ? > > No. Or yeah, we could, but that patch would add no security worth > mentioning. For example, someone could launch a query that runs for > many minutes, and would have plenty of time to conflict with a > subsequently-started postmaster.
True. > Even without that issue, there's no consensus that forcibly making > orphan backends exit would be a good thing. (Some people would > like to have such an option, but the key word in that sentence is > "option".) I believe that multiple people have said multiple times that we should change the behavior so that orphaned backends exit immediately; I think you are the only one defending the current behavior. There are several problems with the status quo: 1. Most seriously, once the postmaster is gone, there's nobody to SIGQUIT remaining backends if somebody exits uncleanly. This means that a backend running without a postmaster could be running in a corrupt shared memory segment, which could lead to all sorts of misbehavior, including possible data corruption. 2. Operationally, orphaned backends prevent the system from being restarted. There's no easy, automatic way to kill them, so scripts that automatically restart the database server if it exits don't work. Even if letting the remaining backends continue to operate is good, not being able to accept new connections is bad enough to completely overshadow it. In many situations, killing them is a small price to pay to get the system back on line. 3. Practically, the performance of any remaining backends will be poor, because processes like the WAL writer and background writer aren't going to be around to help any more. I think this will only get worse over time; certainly, any future parallel query facility won't work if the postmaster isn't around to fork new children. And maybe we'll have other utility processes over time, too. But in any case the situation isn't great right now, either. Now, I don't say that any of this is a reason not to have a strong shared memory interlock, but I'm quite unconvinced that the current behavior should even be optional, let alone the default. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
