Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote: > > On reflection, maybe the problem is not that we're giving the file > > the wrong permissions, but that we're putting it in the wrong place? > > That is, seems like it should be in the logfile directory not the > > data directory. That would certainly simplify the intended use-case, > > and it would fix this complaint too. > > Yeah, thinking more on this one using for this file different > permissions than the log files makes little sense, so what you propose > here seems like a sensible thing to do things. Even if we exclude the > file from native BASE_BACKUP this would not solve the case of custom > backup solutions doing their own copy of things, when they rely on > group-read permissions. This would not solve completely the problem > anyway if log files are in the data folder, but it would address the > case where the log files are in an absolute path out of the data > folder.
Actually, I agree with the initial patch on the basis that this file that's being created (which I'm honestly a bit amazed that we're doing this way; certainly seems rather grotty to me) is surely not an actual *log* file and therefore using logfile_open() to open it doesn't seem quite right. I would have hoped for a way to pass this information that didn't involve a file at all, but I'll assume that was discussed already and good reasons put forth as to why we can't avoid it. I'm not really sure putting it into the logfile directory is such a hot idea as users might have set up external log file rotation of files in that directory. Of course, in that case they'd probably signal PG right afterwards and PG would go write out a new file, but it still seems pretty awkward. I'm not terribly against solving this issue that way either though, but I tend to think the originally proposed patch is more sensible. Thanks! Stephen
signature.asc
Description: PGP signature