Greetings,
* Michael Paquier (michael@paquier.xyz) wrote:
> 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.
As discussed up-thread, if we change current_logfiles to work the way
the rest of our data files do, then base backups would work fine with
the file in its current location. I don't buy how having that file in
the logfiles directory is more "consistent" with anything either- it's
certainly not a log file itself.
> 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).
I agree that we don't need a new GUC for this. I also don't really see
the use-case for this file being directly exposed to users- we have a
function specifically for this information and that's generally how
users should expect to get information like this- or like what the log
directory *is* to begin with, or where other files reside... I sure hope
that we aren't suggesting that asking users to write a parser for
postgresql.conf, with include directories and files, able to also handle
postgresql.auto.conf, is somehow user-friendly.
Thanks!
Stephen
