> On Sep 8, 2022, at 10:43 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > Perry Smith <pedz@xxxxxxxxxxxxxxxx> writes: >> From within the container, files which I assume are created by >> PostgreSQL are ending up being owned by root rather than Postgres. > > If it looks that way from *inside* the container, that's not good > --- wouldn't that prevent Postgres from reading the files? > >> The reason I’m sending this note to the general list is to ask how bad >> is this error? Some “solutions” are to make the pg_stat_tmp directory >> internal to the image and that somehow resolves the issue but I don’t >> think anyone really understands why and things like that bother me. But >> I’m also curious if that appears to be a viable solution. The result >> will be that when the Postgres is stopped and the container exited, the >> next time Postgres starts back up, the pg_stat_tmp directory will be >> gone. Is that ok? > > pg_stat_tmp exists specifically because it holds only temporary files, > cf > > https://www.postgresql.org/docs/devel/storage-file-layout.html > > It's explicitly cleared out during server start. > > The only reason to put it outside the data directory is to make it > *less* persistent than the rest of PG's files, say by putting it > on a RAM disk. You sound like you've set it up to be *more* > persistent (ie outside the container not inside), which surely is > exactly backwards. The data directory is outside so it is persistent. The pg_stat_tmp is inside the data directory. This is how whoever builds the “official” Postgres images set things up. If the right solution is to not make it part of the data directory, I can change that. One of the solutions explains how which solves the Postgres issue but still leaves open the question of how and why do some of the files get owned by root (which probably is a Docker or a Linux issue).
