Re: current_logfiles not following group access and instead follows log_file_mode permissions

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>
Subject: Re: current_logfiles not following group access and instead follows log_file_mode permissions
Date: 2019-01-19 01:49:14
Message-ID: 20190119014914.GE3306@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Fri, Jan 18, 2019 at 09:50:40AM -0500, Stephen Frost wrote:
> It'd probably be good to give folks an opportunity to voice their
> opinion regarding their use-case for the file existing as it does and
> being documented as it is. At first blush, to me anyway, it seems like
> maybe this was a case of "over-documenting" of the feature by including
> in user-facing documentation something that was really there for
> internal reasons, but I could certainly be wrong and maybe there's a
> reason why it's really necessary to have the file around for users.

It's not only that. By keeping the file in its current location, we
can prevent base backups to work even if logs files are out of the
data folder, which is rather user-friendly, and I think that advanced
users of Postgres are careful enough to split log files and main data
folders into different partitions, without symlinks from the data
folder to the log location and with log_directory set to an absolute
path, independent of the rest. So moving current_logfiles out of the
data folder to the base location of the log paths makes quite some
sense in my opinion for consistency.

Using a new GUC to specify where current_logfiles should be located
does not really justify the code complications in my opinion, and I'd
think that we should allow users with log file access to still look at
it, even manually and connected from the host as this can be useful
for debugging purposes (sometimes clocks of systems get changed as
they are not all the time going throuhg ntpd).
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2019-01-19 02:01:07 Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Previous Message Michael Paquier 2019-01-19 01:39:43 Re: Prepare Transaction support for ON COMMIT DROP temporary tables