On Mon, May 3, 2021 at 3:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
This argument doesn't make any sense to me. In almost all cases,
postgres is not init, and if a backend forks a child which stomps on
shared memory and exits, the postmaster will not know that there is a
problem and will not restart. In practice this is not a problem,
because the core code is careful not to touch shared memory in
children that it forks, and extensions written by reasonably smart
people aren't going to do that either, because it's not very hard to
figure out that it can't possibly work. So, in the rare case where
postgres IS init, and it finds out that a descendent process which is
not a direct child has exited, it should do the same thing that we do
in all the other cases where a descendent process that is not a direct
child has exited, viz. nothing. And if that's the wrong idea - I don't
think it is - then we should fix it in all cases, not just the one
where postgres is init.
I don't have a view on whether it is reasonable or prudent to teach
postgres to work as init, because I don't really know what's involved.
But I think you're taking a position that is basically blind panic. If
something happens that we normally wouldn't even know about, and
because of an unusual circumstance we do know about it, we should not
leap to the conclusion that it is something bad. All that does is make
the system behavior less consistent, and thus harder for users.
--
Robert Haas
EDB: http://www.enterprisedb.com