Re: stat() vs ERROR_DELETE_PENDING, round N + 1 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Date
Msg-id YTW28YeDWWgW6o16@paquier.xyz
Whole thread Raw
In response to Re: stat() vs ERROR_DELETE_PENDING, round N + 1  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: stat() vs ERROR_DELETE_PENDING, round N + 1
List pgsql-hackers
> If DeleteFile() is automatically using
> FILE_DISPOSITION_POSIX_SEMANTICS by default when possible on recent
> releases as per the SO link that Andres posted above ("18363.657
> definitely has the new behavior"), then that's great news and maybe we
> shouldn't even bother to try to request that mode ourselves explicitly
> (eg in some kind of unlink wrapper).  Then we'd need just one
> accomodation for older systems and non-NTFS systems, not two, and I
> currently think that should be the short and sweet approach shown in
> 0001-Handle-STATUS_DELETE_PENDING-on-Windows.patch, with some tidying
> and adjustments per feedback.

Having a non-invasive fix for this long-standing issue would be really
great, even if that means reducing the scope of systems where this can
be fixed.

The last time I poked at the bear (54fb8c7d), there was a test posted
by Alexander Lakhin that was really useful in making sure that
concurrency is correctly handled when a file is unlinked:
https://www.postgresql.org/message-id/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com

It worked with VS but not on MinGW.  How does your patch react to this
test?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: pg_dump handling of ALTER DEFAULT PRIVILEGES IN SCHEMA
Next
From: "Drouvot, Bertrand"
Date:
Subject: Extension proposal to deal with existing orphaned files