On Tue, Feb 15, 2022 at 2:09 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
> Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby <pryzby@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+XuwJg@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.y25j42yigwnbdvtg@alap3.anarazel.de