Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-May-03, Andres Freund wrote:
>> The issue turns out to be that postgres was in a container, with pid
>> namespaces enabled. Because postgres was run directly in the container,
>> without a parent process inside, it thus becomes pid 1. Which mostly
>> works without a problem. Until, as the case here with the archive
>> command, a sub-sub process exits while it still has a child. Then that
>> child gets re-parented to postmaster (as init).
> Hah .. interesting. I think we should definitely make this work, since
> containerized stuff is going to become more and more prevalent.
How would we make it "work"? The postmaster can't possibly be expected
to know the right thing to do with unexpected children.
> I guess we can do that in older releases, but do we really need it? As
> I understand, the only thing we need to do is verify that the dying PID
> is a backend PID, and not cause a crash cycle if it isn't.
I think that'd be a net reduction in reliability, not an improvement.
In most scenarios it'd do little except mask bugs. And who's to say
that ignoring unexpected child deaths is okay, anyway? We could hardly
be sure that the dead process hadn't been connected to shared memory.
Maybe we should put in a startup-time check, analogous to the
can't-run-as-root test, that the postmaster mustn't be PID 1.
regards, tom lane
