Re: PG in container w/ pid namespace is init, process exits cause restart

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG in container w/ pid namespace is init, process exits cause restart
Date: 2021-05-03 20:35:37
Message-ID: 20210503203537.xnvghlv7v27bzg5q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-05-03 16:20:43 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2021-05-03 15:37:24 -0400, Tom Lane wrote:
> >> 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.
>
> > I don't think checking the exit status of unexpected children to see
> > whether we should crash-restart out of that concern is meaningful: We
> > don't know that the child didn't do anything bad with shared memory when
> > they exited with exit(1), instead of exit(2).
>
> 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?

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 ...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-05-03 20:49:16 .ready and .done files considered harmful
Previous Message Andrew Dunstan 2021-05-03 20:32:38 Re: PG in container w/ pid namespace is init, process exits cause restart