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

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>
Date: 2021-09-02T10:28:09Z
Lists: pgsql-hackers
On Thu, Sep 2, 2021 at 10:10 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Perhaps we need some combination of the old way (that apparently knew
> how to detect pending deletes) and the new way (that knows about large
> files)?

I tried that, but as far as I can tell, the old approach didn't really
work either :-(

A disruptive solution that works in my tests: we could reuse the
global barrier proposed in CF #2962.  If you see EACCES, ask every
backend to close all vfds at their next CFI() and wait for them all to
finish, and then retry.  If you get EACCES again it really means
EACCES, but you'll very probably get ENOENT.

The cheapest solution would be to assume EACCES really means ENOENT,
but that seems unacceptably incorrect.

I suspect it might be possible to use underdocumented/unstable NtXXX()
interfaces to get at the information, but I don't know much about
that.

Is there another way that is cheap, correct and documented?



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