Hi,
On 2021-05-03 15:25:53 -0400, Alvaro Herrera wrote:
> I also heard a story where things ran into trouble (I didn't get the
> whole story of *what* was the problem with that) because the datadir is /.
> I know -- nobody in their right mind would put the datadir in / -- but
> apparently in the container world that's not something as stupid as it
> sounds. That's of course not related to what you describe here
> code-wise, but the underlying reason is the same.
It still seems pretty insane in the container world too. Postgres needs
shared libraries (even if you managed to link postgres itself
statically, something we do not support). Postgres needs to write to the
data directory. Putting shared libraries inside the data directory seems
like a bad idea.
Using / for a single statically linked binary that e.g. just serves a
bunch of hardcoded files is one thing. Putting actual data in / for
something like postgres another.
> > I wonder if we should work a bit harder to try to identify whether an
> > exiting process was a "server process" before identifying it as such?
>
> Well, we've never made any effort there because it just wasn't possible.
> Nobody ever had postmaster also be init .. until containers. Let's fix
> it.
> > And perhaps we ought to warn about postgres running as "init" unless we
> > make that robust?
>
> 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 there's a few more special cases when running as init, other
than reparenting. E.g. I think the default signal handlers are
different, the kernel kills the process in fewer cases etc. I am not
opposed to adding support for it, but I think it'd need a bit of care.
Given that we probably shouldn't just break things in a minor release by
refusing to run as 1, a warning seems to be the easiest thing for now?
Greetings,
Andres Freund
