Re: PG in container w/ pid namespace is init, process exits cause restart

Greg Stark <stark(at)mit(dot)edu> writes:
> On Mon, 3 May 2021 at 15:44, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, as far as that goes, I think the general recommendation is that
>> the datadir shouldn't be a mount point, because bad things happen if
>> you mount or unmount the drive while the postmaster is up. I could
>> see enforcing that, if we could find a reasonably platform-independent
>> way to do it.

> I don't think the problem is unmounting -- on BSD you have to try
> really hard to unmount filesystems that have files open on them and
> afaik you can't do it on Linux at all (which I still claim is the
> original sin that led to the fsync issues).
> The problem was mounting filesystems if it happened late -- ie. After
> Postgres had started up. It was exacerbated by some startup scripts
> that would automatically run initdb if there was nothing present.

Yeah, at least that was the case that somebody (Joe Conway if memory
serves) reported years ago.

> Offhand I don't actually see anything special about the Postgres
> directory root being the mountpoint though.

I think one good reason not to do it is that a mount point directory
ought to be root-owned. I don't recall the specific reasoning
behind that practice, but it seems sound. Also, if the filesystem
is one that likes having a lost+found directory, you have some
finagling to do to keep initdb from complaining about that.

> Fwiw, I have a suspicion that the right check for being init is
> whether `pid == ppid`.

Makes sense, and seems nicer than hard-coding an assumption that
PID 1 is special.

regards, tom lane