Re: Function pg_database_size fails with "Permission denied" on a corrupted fsm file

On Fri, Jun 21, 2019 at 02:41:35AM +0000, Steve Komarov wrote:
> Other info:
> I found a discussion of a similar "Permission Denied" error dating
> all the way back to 2010:
> https://www.postgresql.org/message-id/db471ace1001291612l5b21d85du296e4820553e0365%40mail.gmail.com
> The suspected culprit in the linked case was the AV software, which
> is why I tried disabling the AV software in my trials. It made no
> difference.

Yes, Windows has a long history of causing stat() to fail on EACCES if
a file is pending for deletion. The root of the issue if that a file
pending for deletion is not actually removed physically from disk
until all the other processes still holding a handle to it close their
handles. If a process decides to unlink() the file, then the file
is marked as pending for deletion, with special icacls markers. And
when bumping on that stat() does *not* complain about ENOENT (or
ERROR_DELETE_PENDING if you want) but EACCES. I am not sure that
there is much we can do here if we cannot detect reliably if a file is
pending for deletion. Postgres should report the error the OS tells,
and we should not try to outsmart what's reported. Mapping silently
EACCES to ENOENT is not a solution either, as there could be an
anti-virus software holding an exclusive lock on a file causing a
legit EACCES, and we need to detect that properly, not thinking
transparently that the file is simply gone.
--
Michael