Thread: 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: https://postgr.es/m/CA%2BhUKGJz_pZTF9mckn6XgSv69%2BjGwdgLkxZ6b3NWGLBCVjqUZA%40mail.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