Re: kill -KILL: What happens?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
>> It sucks because you don't get a signal on parent death. With the
>> arrival of the latch code, having to check for PostmasterIsAlive
>> frequently is the only reason for an idle background process to consume
>> CPU at all.

> What we really need is SIGPARENT. I wonder if the Linux folks would
> consider adding such a thing. Might be useful to others as well.

That's pretty much a dead-end idea unfortunately; it would never be
portable enough to let us change our system structure to rely on it.
Even more to the point, "go away when the postmaster does" isn't
really the behavior we want anyway. "Go away when the last backend
does" is what we want.

I wonder whether we could have some sort of latch-like counter that
would count the number of active backends and deliver signals when the
count went to zero. However, if the goal is to defend against random
applications of SIGKILL, there's probably no way to make this reliable
in userspace.

Another idea is to have a "postmaster minder" process that respawns the
postmaster when it's killed. The hard part of that is that the minder
can't be connected to shared memory (else its OOM cross-section is just
as big as the postmaster's), and that makes it difficult for it to tell
when all the children have gone away. I suppose it could be coded to
just retry every few seconds until success. This doesn't improve the
behavior of background processes at all, though.

regards, tom lane