Robert Haas <robertmhaas@gmail.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