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.
I've attached a patch which emits a LOG message for ENOENT. The exact
wording doesn't matter to me, I'm sure someone can improve it.
Alternatively, perhaps the message a few lines down, "could not restore
file", could get promoted from DEBUG2 to LOG when rc indicates success.
But I don't think we need any more messages which say "Something went
wrong: success".
This is based on the question at
https://stackoverflow.com/questions/60056597/couldnt-restore-postgres-v11-from-pg-basebackup.
But this isn' the first time I've seen similar confusion.
Cheers,
Jeff
restore_log.patch
Description: Binary data
