Greetings, * Michael Paquier (mich...@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
signature.asc
Description: PGP signature
