On Tue, Jan 15, 2019 at 03:08:41PM +1100, Haribabu Kommi wrote: > current_logfiles is a meta data file, that stores the current log writing > file, and this file presents in the data directory. This file > doesn't follow the group access mode set at the initdb time, but it > follows the log_file_mode permissions. > > Without group access permissions, backup with group access can lead to > failure. Attached patch fix the problem.
initdb enforces log_file_mode to 0640 when using the group mode, still if one enforces the parameter value then current_logfiles would just stick with it. This is not really user-friendly. This impacts also normal log files as these get included in base backups if the log path is within the data folder (not everybody uses an absolute path out of the data folder for the logs). One way to think about this is that we may want to worry also about normal log files and document that one had better be careful with the setting of log_file_mode? Still, as we are talking about a file aiming at storing meta-data for log files, something like what you suggest can make sense. When discussing about pg_current_logfile(), I raised the point about not including as well in base backups which would also address the problem reported here. However we decided to keep it because it can be helpful to know what's the last log file associated to a base backup for debugging purposes: https://www.postgresql.org/message-id/50b58f25-ab07-f6bd-7a68-68f29f214...@dalibo.com Instead of what you are proposing, why not revisiting that and just exclude the file from base backups. I would be in favor of just doing that instead of switching the file's permission from log_file_mode to pg_file_create_mode. -- Michael
signature.asc
Description: PGP signature
