On Tue, Mar 12, 2019 at 2:03 AM Michael Paquier <mich...@paquier.xyz> wrote: > On Tue, Feb 26, 2019 at 12:22:53PM +1100, Haribabu Kommi wrote: > > I checked the code why the current_logfiles is not implemented as > > shared memory and found that the current syslogger doesn't attach to > > the shared memory of the postmaster. To support storing the > > current_logfiles in shared memory, the syslogger process also needs > > to attach to the shared memory, this seems to be a new > > infrastructure change. > > I don't think you can do that anyway and we should not do it. Shared > memory can be reset after a backend exits abnormally, but the > syslogger lives across that.
I think we should do what Haribabu proposed originally. Moving current_logfiles out of the data directory doesn't make sense, because: (1) If you're trying to find the log files, having a file that contains their pathnames in the place where those files are does not help you. Having such a file in the known location, namely the data directory, does. (2) Someone might have logs from multiple PostgreSQL clusters in the same external log directory, but there can only be one file named current_logfiles. (3) Someone might store PostgreSQL log files in the same directory as non-PostgreSQL log files, and having a file called current_logfiles floating around will be confusingly ambiguous. On the other hand, changing the file to have the same permissions as everything else in the data directory has basically no disadvantages. I agree with Stephen's analysis that a file containing the names of the current log files is not itself a log file. Tom's idea that making the permissions consistent with everything else in the data directory would "break its only use-case" seems completely wrong. Anybody who has permission to read the log files but not the data directory will presumably hit the directory-level permissions on $PGDATA before the issue of the permissions on current_logfiles() per se become relevant, except in corner cases that I don't care about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company