Re: PG in container w/ pid namespace is init, process exits cause restart - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PG in container w/ pid namespace is init, process exits cause restart
Date
Msg-id 3850191.1620076429@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG in container w/ pid namespace is init, process exits cause restart  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2021-05-03 16:20:43 -0400, Tom Lane wrote:
>> Hmm, by that argument, any unexpected child PID in reaper() ought to be
>> grounds for a restart, regardless of its exit code.  Which'd be fine by
>> me.  I'm on board with being more restrictive about this, not less so.

> Are there any holes / races that could lead to this "legitimately"
> happening? To me the signal blocking looks like it should prevent that?

If it did happen it would imply a bug in the postmaster's child-process
bookkeeping.

(Or, I guess, some preloaded module deciding that launching its own
children was OK, whether or not it could find out whether they
succeeded.)

> I'm a bit worried that we'd find some harmless corner cases under adding
> a new instability. So personally I'd be inclined to just make it a
> warning, but ...

Well, I wouldn't recommend adding such a check in released branches,
but I'd be in favor of changing it in HEAD (or waiting till v15
opens).

Meanwhile, it seems like we both thought of complaining if the
postmaster's PID is 1.  I'm not quite sure if there are any
portability hazards from that, but on the whole it sounds like
a good way to detect badly-configured containers.

            regards, tom lane



pgsql-hackers by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart
Next
From: Melanie Plageman
Date:
Subject: Re: Avoiding smgrimmedsync() during nbtree index builds