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