Re: Assorted Win32 error handling fixes (CreateThread, pgwin32_select, pg_usleep)

From: Harrison Booth <harrisontbooth(at)gmail(dot)com>
To: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assorted Win32 error handling fixes (CreateThread, pgwin32_select, pg_usleep)
Date: 2026-10-13 01:33:52
Message-ID: CAAH-eSVg7xpBs2SbrDnxw_orcwt_DECbmtHMfXWNpBxQv4_EbQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sehrope,

I reviewed all four v2 patches against master 8e82d6610e7 and found no
correctness blocker introduced by the changes. Builds passed on native
Windows ARM64 and emulated x64, with the other Windows changes in my
validation checkout applied as well.

I also tested source-extracted probes on both architectures. Returning
NULL from the affected CreateThread calls reaches the revised fatal
branches; the original checks miss it. An invalid event handle
produces WAIT_FAILED and reaches the revised pg_usleep fatal branch.
Timeout, signal dispatch/EINTR, and the startup NULL-handle fallback
retain their behavior. These probes use test fatal handlers rather
than a complete instrumented backend.

For the array change, a synthetic full-capacity boundary probe
overwrites the guard with the original allocation and preserves it
with the extra slot. This verifies the bounds calculation, not a
successful wait with that many handles. The existing
MAXIMUM_WAIT_OBJECTS limit is a separate issue and doesn't block this
correction.

Happy to provide the probe sources if useful.

Best,

Harrison

Original discussion:
https://www.postgresql.org/message-id/CAH7T-apQipawP3XoUk=9yPTazDZsYHsfKrpPUygFk3UDGbCb3w@mail.gmail.com

Browse pgsql-hackers by date

  From Date Subject
Next Message Harrison Booth 2026-10-13 01:33:56 Re: Windows locales and tests portability
Previous Message Richard Guo 2026-10-13 01:32:57 Wrong results from a mergejoin