On Thu, Aug 6, 2026 at 8:39 AM Michael Paquier <[email protected]> wrote:
>
> On Thu, Aug 06, 2026 at 07:16:43AM +0900, Michael Paquier wrote:
> > I'll do that, and likely apply the result.  Another part is if this
> > should be backpatched or not, but I always find these recovery changes
> > quite stressing to do in stable branches, so for now I'd tend to just
> > do this change on HEAD, also due to the fact that we don't seem to
> > have reports about this tiny window being a problem in practice.
>
> I have added a note about the window still existing on WIN32, and
> applied the result as 1200dfd60c36 on HEAD.

Thanks for working on this!

This isn't directly related to this commit, but while reading the modified code
I found a small pre-existing issue in the WIN32 path.

In KeepFileRestoredFromArchive(), if unlink(oldpath) fails, the error message
reports xlogfpath, even though the file being removed is actually oldpath:

      if (unlink(oldpath) != 0)
          ereport(FATAL,
                  (errcode_for_file_access(),
                   errmsg("could not remove file \"%s\": %m",
                          xlogfpath)));

Should we fix that as well?

Regards,

-- 
Fujii Masao


Reply via email to