Re: PG in container w/ pid namespace is init, process exits cause restart
От | Tom Lane |
---|---|
Тема | Re: PG in container w/ pid namespace is init, process exits cause restart |
Дата | |
Msg-id | 3850191.1620076429@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PG in container w/ pid namespace is init, process exits cause restart (Andres Freund <andres@anarazel.de>) |
Список | 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 по дате отправления: