Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
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:31:51Z
Lists: pgsql-hackers
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? regards, tom lane
Commits
-
Check for STATUS_DELETE_PENDING on Windows.
- e2f0f8ed251d 15.0 landed
-
Fix our Windows stat() emulation to handle file sizes > 4GB.
- bed90759fcbc 14.0 cited
-
Attempt to handle pending-delete files on Windows
- 9951741bbeb3 10.0 cited