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
orescaping or quoting issues, for example), no complaint is issued at the time, and it then fails later with a
relativelyuninformative 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
("restoredlog 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