On Tue, Mar 12, 2019 at 2:03 AM Michael Paquier <michael@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