Re: Error logging messages

> On 14 Apr 2022, at 09:10, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Apr 13, 2022 at 01:51:16PM +0200, Daniel Gustafsson wrote:
>> 0001: Makes sure that database and file names are printed quoted.  This patch
>> has hunks in contrib and backend as well.
>>
>> 0002: Capitalizes pg_log_error_detail and conversely starts pg_log_error with a
>> lowercase letter without punctuation.
>>
>> 0003: Extend a few messages with more information to be more consistent with
>> other messages (and more helpful).
>>
>> 0005: Put keywords as parameters in a few pg_dump error messages, to make their
>> translations reuseable.
>
> These look fine.

Thanks

>> 0004: Add pg_log_error() calls on all calls to close in pg_basebackup.  Nearly
>> all had already, and while errors here are likely to be rare, when they do
>> happen something is really wrong and every bit of information can help
>> debugging.
>
> +               if (stream->walmethod->close(f, CLOSE_UNLINK) != 0)
> +                    pg_log_error("could not delete write-ahead log file \"%s\": %s",
> +                    fn, stream->walmethod->getlasterror());
> With only the file names provided, it is possible to know that this is
> a WAL file.  Could we switch to a simpler "could not delete file
> \"%s\"" instead?  Same comment for the history file and the fsync
> failure a couple of lines above.

I don't have strong opinions, simplifying makes it easier on translators (due
to reuse) and keeping the verbose message may make it easier for users
experiencing problems.

--
Daniel Gustafsson        https://vmware.com/