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=9yptazdzsyhsfkrppuygfk3udgbc...@mail.gmail.com
