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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: current_logfiles not following group access and instead follows log_file_mode permissions
Date: 2019-01-15 05:15:50
Message-ID: 20190115051550.GE1433@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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-68f29f214ce9@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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-15 05:46:55 Re: Proving IS NOT NULL inference for ScalarArrayOpExpr's
Previous Message Ashutosh Bapat 2019-01-15 04:29:23 Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0