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
Дата
в 19:37:24
Msg-id
3839054.1620070644@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
PG in container w/ pid namespace is init, process exits cause restart Andres Freund <andres@anarazel.de>
Re: PG in container w/ pid namespace is init, process exits cause restart Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: PG in container w/ pid namespace is init, process exits cause restart Andres Freund <andres@anarazel.de>
Re: PG in container w/ pid namespace is init, process exits cause restart Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Andres Freund <andres@anarazel.de>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Andres Freund <andres@anarazel.de>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Re: PG in container w/ pid namespace is init, process exits cause restart Andrew Dunstan <andrew@dunslane.net>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Robert Haas <robertmhaas@gmail.com>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Robert Haas <robertmhaas@gmail.com>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Robert Haas <robertmhaas@gmail.com>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Alvaro Herrera <alvherre@alvh.no-ip.org>
Re: PG in container w/ pid namespace is init, process exits cause restart Greg Stark <stark@mit.edu>
Re: PG in container w/ pid namespace is init, process exits cause restart Justin Pryzby <pryzby@telsasoft.com>
Re: PG in container w/ pid namespace is init, process exits cause restart Tom Lane <tgl@sss.pgh.pa.us>
Re: PG in container w/ pid namespace is init, process exits cause restart Joe Conway <mail@joeconway.com>
Re: PG in container w/ pid namespace is init, process exits cause restart Andrew Dunstan <andrew@dunslane.net>
Alvaro Herrera  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


В списке pgsql-hackers по дате отправления
От: Joel Jacobson
Дата:
От: Tom Lane
Дата:
FAQ