Re: current_logfiles not following group access and instead followslog_file_mode permissions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: current_logfiles not following group access and instead followslog_file_mode permissions
Date
Msg-id 20190324122645.GB2558@paquier.xyz
Whole thread Raw
In response to Re: current_logfiles not following group access and instead followslog_file_mode permissions  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Sun, Mar 24, 2019 at 09:16:44PM +0900, Michael Paquier wrote:
> After testing and reviewing the patch, I noticed that all versions
> sent up to now missed two things done by logfile_open():
> - Bufferring is line-buffered.  For current_logfiles it may not matter
> much as the contents are first written into a temporary file and then
> the file is renamed, but for debugging having the insurance of
> consistent contents is nice even for the temporary file.
> - current_logfiles uses \r\n.  While it does not have a consequence
> for the parsing of the file by pg_current_logfile, it breaks the
> readability of the file on Windows, which is not nice.
> So I have kept the patch with the previous defaults for consistency.
> Perhaps they could be changed, but the current set is a good set.

By the way, this also fixes a cosmetic issue with a failure in
creating current_logfiles: when update_metainfo_datafile() fails to
create the file, it logs a LOG message, but logfile_open() does the
same thing, so this finishes with two log entries for the same
failure.  v10 still has that issue, I don't think that it is worth
fixing as it has no actual consequence except perhaps bringing some
confusion.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: current_logfiles not following group access and instead followslog_file_mode permissions
Next
From: Michael Paquier
Date:
Subject: Re: Adding a TAP test checking data consistency on standby withminRecoveryPoint