pgsql: Check for STATUS_DELETE_PENDING on Windows.
Check for STATUS_DELETE_PENDING on Windows.
1. Update our open() wrapper to check for NT's STATUS_DELETE_PENDING
and translate it to Unix-like errors. This is done with
RtlGetLastNtStatus(), which is dynamically loaded from ntdll. A new
file win32ntdll.c centralizes lookup of NT functions, in case we decide
to add more in the future.
2. Remove non-working code that was trying to do something similar for
stat(), and just reuse the open() wrapper code. As a side effect,
stat() also gains resilience against "sharing violation" errors.
3. Since stat() is used very early in process startup, remove the
requirement that the Win32 signal event has been created before
pgwin32_open_handle() is reached. Instead, teach pg_usleep() to fall
back to a non-interruptible sleep if reached before the signal event is
available.
This could be back-patched, but for now it's in master only. The
problem has apparently been with us for a long time and generated only a
few complaints. Proposed patches trigger it more often, which led to
this investigation and fix.
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>
Discussion: /messages/by-id/CA+hUKGJz_pZTF9mckn6XgSv69+jGwdgLkxZ6b3NWGLBCVjqUZA@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e2f0f8ed251d02c1eda79e1ca3cb3db2681e7a86
Modified Files
--------------
configure | 6 ++
configure.ac | 1 +
src/backend/port/win32/signal.c | 12 ++-
src/include/port.h | 1 +
src/include/port/win32ntdll.h | 27 +++++++
src/port/open.c | 104 +++++++++++++------------
src/port/win32ntdll.c | 69 +++++++++++++++++
src/port/win32stat.c | 164 ++--------------------------------------
src/tools/msvc/Mkvcbuild.pm | 3 +-
9 files changed, 178 insertions(+), 209 deletions(-)
Thomas Munro <tmunro@postgresql.org> writes:
Check for STATUS_DELETE_PENDING on Windows.
The src/include/port/win32ntdll.h file added by this commit has
a couple of deficiencies:
1. It lacks the usual anti-multiple-inclusion guard, i.e.
#ifndef WIN32NTDLL_H
or the like. Was there a specific reason to omit that?
2. headerscheck and cpluspluscheck don't like it, at least
not on non-Windows:
$ src/tools/pginclude/headerscheck
In file included from /tmp/headerscheck.WKh8cz/test.c:2:
./src/include/port/win32ntdll.h:20:10: fatal error: ntstatus.h: No such file or directory
#include <ntstatus.h>
^~~~~~~~~~~~
One way to solve that, perhaps, is to wrap the whole header
in #ifdef WIN32. But I think our more usual practice has
been to add such headers to the exclusion lists in those
two scripts.
regards, tom lane
On Wed, Jan 12, 2022 at 8:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
1. It lacks the usual anti-multiple-inclusion guard, i.e.
#ifndef WIN32NTDLL_H
or the like. Was there a specific reason to omit that?
Oops. Fixed.
2. headerscheck and cpluspluscheck don't like it, at least
not on non-Windows:$ src/tools/pginclude/headerscheck
In file included from /tmp/headerscheck.WKh8cz/test.c:2:
./src/include/port/win32ntdll.h:20:10: fatal error: ntstatus.h: No such file or directory
#include <ntstatus.h>
^~~~~~~~~~~~One way to solve that, perhaps, is to wrap the whole header
in #ifdef WIN32. But I think our more usual practice has
been to add such headers to the exclusion lists in those
two scripts.
Done.
Those scripts aren't really on my radar... would it be a good idea to
run them as steps in the CompilerWarnings CI task?
On 1/11/22 16:22, Thomas Munro wrote:
2. headerscheck and cpluspluscheck don't like it, at least
not on non-Windows:
$ src/tools/pginclude/headerscheck
In file included from /tmp/headerscheck.WKh8cz/test.c:2:
./src/include/port/win32ntdll.h:20:10: fatal error: ntstatus.h: No such file or directory
#include <ntstatus.h>
^~~~~~~~~~~~One way to solve that, perhaps, is to wrap the whole header
in #ifdef WIN32. But I think our more usual practice has
been to add such headers to the exclusion lists in those
two scripts.Done.
Those scripts aren't really on my radar... would it be a good idea to
run them as steps in the CompilerWarnings CI task?
Or in a buildfarm module (c.f. the perl checks)
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
On 1/11/22 16:22, Thomas Munro wrote:
Those scripts aren't really on my radar... would it be a good idea to
run them as steps in the CompilerWarnings CI task?
Or in a buildfarm module (c.f. the perl checks)
+1 for one or the other, because we break that regularly and it
typically takes awhile to notice.
regards, tom lane
On 1/11/22 16:54, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 1/11/22 16:22, Thomas Munro wrote:
Those scripts aren't really on my radar... would it be a good idea to
run them as steps in the CompilerWarnings CI task?Or in a buildfarm module (c.f. the perl checks)
+1 for one or the other, because we break that regularly and it
typically takes awhile to notice.
Done See
<https://github.com/PGBuildFarm/client-code/commit/51a6f79ec16de87a7eba7a66015985998311d465>
crake will now run this as part of its normal runs on HEAD.
cheers
andew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Andrew Dunstan <andrew@dunslane.net> writes:
Done See
<https://github.com/PGBuildFarm/client-code/commit/51a6f79ec16de87a7eba7a66015985998311d465>
crake will now run this as part of its normal runs on HEAD.
Great, thanks!
regards, tom lane