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?
Because the parameter MOVEFILE_COPY_ALLOWED,
which leads Windows to use another algorithm, perhaps.
Only MOVEFILE_REPLACE_EXISTING does not solve it.
Have you seen this?
https://commitfest.postgresql.org/37/3347/
Postgres really need an atomic rename in Windows?
I think working, rename can be not atomic and take 1s.
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.
My local environment is:
Windows 10 Home (64 bits)
21H2 build 19044.1526
With Postgres v14.2 and HEAD,
enough starting the server, without any user connected
to log appears.
With the patch, the log no longer occurs
and the renamed file appears in the dir command listing.
Does this answer the question about FileMoveEx?
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) Apparently solves, but not tested with heavy load and many users.
regards,
Ranier Vilela
