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
