Re: bad logging around broken restore_command

On 2020/02/06 1:10, Jeff Janes wrote:
> If the restore command claims to have succeeded, but fails to have created a file with the right name (due to typos or escaping or quoting issues, for example), no complaint is issued at the time, and it then fails later with a relatively uninformative error message like "could not locate required checkpoint record".
>
>     if (rc == 0)
>     {
>         /*
>          * command apparently succeeded, but let's make sure the file is
>          * really there now and has the correct size.
>          */
>         if (stat(xlogpath, &stat_buf) == 0)
>         {......
>         }
>         else
>         {
>             /* stat failed */
>             if (errno != ENOENT)
>                 ereport(FATAL,
>                         (errcode_for_file_access(),
>                          errmsg("could not stat file \"%s\": %m",
>                                 xlogpath)));
>         }
>
> I don't see why ENOENT is thought to deserve the silent treatment.  It seems weird that success gets logged ("restored log file \"%s\" from archive"), but one particular type of unexpected failure does not.

Agreed.

> I've attached a patch which emits a LOG message for ENOENT.

Isn't it better to use "could not stat file" message even in ENOENT case?
If yes, something like message that you used in the patch should be
logged as DETAIL or HINT message. So, what about the attached patch?

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters