Skip to content

Commit a69f569

Browse files
committed
In pgwin32_open, loop after ERROR_ACCESS_DENIED only if we can't stat.
This fixes a performance problem introduced by commit 6d7547c. ERROR_ACCESS_DENIED is returned in some other cases besides the delete-pending case considered by that commit; notably, if the given path names a directory instead of a plain file. In that case we'll uselessly loop for 1 second before returning the failure condition. That slows down some usage scenarios enough to cause test timeout failures on our Windows buildfarm critters. To fix, try to stat() the file, and sleep/loop only if that fails. It will fail in the delete-pending case, and also in the case where the deletion completed before we could stat(), so we have the cases where we want to loop covered. In the directory case, the stat() should succeed, letting us exit without a wait. One case where we'll still wait uselessly is if the access-denied problem pertains to a directory in the given pathname. But we don't expect that to happen in any performance-critical code path. There might be room to refine this further, but I'll push it now in hopes of making the buildfarm green again. Back-patch, like the preceding commit. Alexander Lakhin and Tom Lane Discussion: https://postgr.es/m/23073.1576626626@sss.pgh.pa.us
1 parent 0751292 commit a69f569

File tree

1 file changed

+23
-7
lines changed

1 file changed

+23
-7
lines changed

src/port/open.c

Lines changed: 23 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@
2121

2222
#include <fcntl.h>
2323
#include <assert.h>
24+
#include <sys/stat.h>
2425

2526

2627
static int
@@ -120,18 +121,33 @@ pgwin32_open(const char *fileName, int fileFlags,...)
120121
}
121122

122123
/*
123-
* ERROR_ACCESS_DENIED can be returned if the file is deleted but not
124-
* yet gone (Windows NT status code is STATUS_DELETE_PENDING). Wait a
125-
* bit and try again, giving up after 1 second (since this condition
126-
* should never persist very long).
124+
* ERROR_ACCESS_DENIED is returned if the file is deleted but not yet
125+
* gone (Windows NT status code is STATUS_DELETE_PENDING). In that
126+
* case we want to wait a bit and try again, giving up after 1 second
127+
* (since this condition should never persist very long). However,
128+
* there are other commonly-hit cases that return ERROR_ACCESS_DENIED,
129+
* so care is needed. In particular that happens if we try to open a
130+
* directory, or of course if there's an actual file-permissions
131+
* problem. To distinguish these cases, try a stat(). In the
132+
* delete-pending case, it will either also get STATUS_DELETE_PENDING,
133+
* or it will see the file as gone and fail with ENOENT. In other
134+
* cases it will usually succeed. The only somewhat-likely case where
135+
* this coding will uselessly wait is if there's a permissions problem
136+
* with a containing directory, which we hope will never happen in any
137+
* performance-critical code paths.
127138
*/
128139
if (err == ERROR_ACCESS_DENIED)
129140
{
130141
if (loops < 10)
131142
{
132-
pg_usleep(100000);
133-
loops++;
134-
continue;
143+
struct stat st;
144+
145+
if (stat(fileName, &st) != 0)
146+
{
147+
pg_usleep(100000);
148+
loops++;
149+
continue;
150+
}
135151
}
136152
}
137153

0 commit comments

Comments
 (0)