From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(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-06 01:31:43 |
Message-ID: | 4102933.1620264703@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I have to admit that I care less about the specific issue here than
> about the general issue of being open to hearing what the user needs
> actually are. I honestly have no idea whether it's sensible to want to
> run postgres as init. If people who know about container stuff say
> that's a dumb idea and you shouldn't do it, then IMHO your conclusion
> that we should simply disallow it is 100% correct. But if those people
> show up and say, no, it's actually super-convenient for postgres to
> run as init and using one of those shim things has significant
> downsides that are hard to mitigate, and if further we could do what
> they say they need with just a little bit of extra code, then IMHO
> your conclusion is 100% wrong. Now so far as I can see right now
> neither conclusion is crystal clear - opinions seem to be a bit mixed.
> So right now I don't really know what to think. I just don't want to
> fall into the trap of thinking that core developers are somehow in a
> better place to know the right answer than users.
I don't claim to have an opinion about how convenient it would be
for users to not need an init shim. I do claim to have a qualified
opinion about how hard it would be for us to support the case. It'd
hobble our ability to detect child-process bookkeeping errors, and
it'd put constraints on how we manage the postmaster's signal handling.
Maybe those constraints will never matter, but that's a contract I
don't really want to buy into for this seemingly-not-large benefit.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2021-05-06 01:32:28 | Re: MaxOffsetNumber for Table AMs |
Previous Message | Hannu Krosing | 2021-05-06 01:26:22 | Re: MaxOffsetNumber for Table AMs |