On 04.06.2019 3:18, Michael Paquier wrote:
On Mon, Jun 03, 2019 at 11:37:30PM +0300, Konstantin Knizhnik wrote:
but without success because ERROR_DELETE_PENDING is never returned by Win32.
And moreover, stat() doesn't ever return error in this case.
Could it be possible to find a reliable way to detect that?
Cloberring errno with an incorrect value is not something we can rely
on, and I am ready to buy that GetFileAttributesEx() can also return
EACCES for some legit cases, like a file it has no access to. What
if for example something is done on a file between the stat() call and
the GetFileAttributesEx() call in pgwin32_safestat() so as EACCES is
a legit error?
Sorry, I am not a Windows expert so I do not know how if it is possible
to detect that ERROR_ACCESS_DENIED returned by GetFileAttributesEx is
actually caused by pending delete.
The situation when file permissions were changed between call of stat()
and GetFileAttributesEx() is certainly possible but... do your really
seriously consider probability of this event
and is there something critical if we return ENOENT instead of EACCES in
this case?
Actually original problem seems to be caused by the assumption that
stat() is not correctly setting st_size at Windows:
/*
* The stat() function in win32 is not guaranteed to update the st_size
* field when run. So we define our own version that uses the Win32 API
* to update this field.
*/
I tried to google information about such behavior but didn't find any
other references except Postgres sources.
I wonder if such problem really takes place (at least with more or less
recent versions of Windows)?
And how critical it can be that we get cached value of file size?
If we access file without locking, then it is not correct to say about
the "actual" file size, isn't it? File can be truncated or appended few
milliseconds later after this call.
If there are some places in Postgres code which rely on the fact that
stat() returns the "latest" file size value (actual for the moment of
stat() call), then it can be a sign of possible race condition.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
