On Thu, Jul 31, 2014 at 9:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Baker, Keith [OCDUS Non-J&J]" <KBaker9@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
