On Tue, Feb 15, 2022 at 2:09 PM Ranier Vilela <ranier...@gmail.com> wrote: > Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby <pry...@telsasoft.com> > escreveu: >> On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote: >> > I've reported this issue, but without success in fixing it. >> >> It'd be helpful to provide a link to the prior discussions, and summarize it. >> >> https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items >> https://www.postgresql.org/message-id/CAEudQAoR5e7=umz0otzucvb25ztc8qqbe+2dt1jrsa3u+xu...@mail.gmail.com >> >> See also e2f0f8ed251d02c1eda79e1ca3cb3db2681e7a86 > > I can't be sure if this is a case of DELETE_PENDING, > but FlieMoveEx apparently solves it.
Can you explain why it solves it? Have you seen this? https://commitfest.postgresql.org/37/3347/ Do you know if FileMoveEx might be magically doing POSIX-style operations when NTFS is used, on some recent version of Windows, as was described at [1][2] with respect to DeleteFileEx? CF #3347 is about explicitly asking for those semantics, but [1] says that the need to do that might be going away. One of the reasons I have been putting off committing #3347 (other than my desire to remove the pre-Win10 support) is (1) the hypothesis that the problem might become simpler to solve as of some Windows 10 version as you might be seeing with your FileMoveEx test and (2) I'm not sure how to handle the fact that once all the build farm animals and CI systems are using POSIX semantics on NTFS, we'll have no testing of the non-POSIX/traditional Windows semantics. I mean stuff like e2f0f8ed. I suppose we really should have a non-NTFS build farm animal, and I think we should have something like pg_test_dirmod.exe that runs through a bunch of standalone tests. [1] https://stackoverflow.com/questions/60424732/did-the-behaviour-of-deleted-files-open-with-fileshare-delete-change-on-windows [2] https://www.postgresql.org/message-id/20210905214437.y25j42yigwnbd...@alap3.anarazel.de
