Re: stat() vs ERROR_DELETE_PENDING, round N + 1

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Date: 2021-09-06T06:36:33Z
Lists: 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

Commits

  1. Check for STATUS_DELETE_PENDING on Windows.

  2. Fix our Windows stat() emulation to handle file sizes > 4GB.

  3. Attempt to handle pending-delete files on Windows