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

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>, Michael Paquier <michael@paquier.xyz>
Date: 2021-09-02T10:51:06Z
Lists: pgsql-hackers
On Thu, Sep 2, 2021 at 10:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > 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.
>
> That seems quite horrid :-(.  But if it works, doesn't that mean that
> somewhere we are opening a problematic file without the correct
> sharing flags?

I'm no expert, but not AFAICS.  We managed to delete the file while
some other backend had it open, which FILE_SHARE_DELETE allowed.  We
just can't open it or create a new file with the same name until it's
really gone (all handles closed).



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