Re: low wal_retrieve_retry_interval causes missed signals on Windows

Alexander,

I reproduced this on current master 38afc3dcb25 using Meson 1.11.2 and
MSVC 19.44 on Windows 11 ARM64.

The native ARM64 full suite failed at the pg_ctl promote step, although
an isolated rerun passed all 12 subtests. The x64-on-ARM64 build failed
at the same step after 89.92 seconds in the full suite and again after
85.77 seconds in an isolated rerun.

I then ported and tested both of Nathan Bossart's 2023 proposals:

- v1 always calls WaitLatch(), with a zero timeout if the retry interval
has already elapsed.
- v2 dispatches queued Windows signals in the startup, checkpointer, and
archiver interrupt handlers.

For each patch, recovery/002_archiving passed five consecutive times on
x64-on-ARM64 and three consecutive times on native ARM64, with all 12
subtests passing. recovery/001_stream_rep and
recovery/020_archive_status also passed on both configurations.

Nathan's v1 and v2:
https://www.postgresql.org/message-id/20230111061116.GA1668254%40nathanxps13
https://www.postgresql.org/message-id/20230111232645.GA1957467%40nathanxps13

Andres considered the v1 approach incomplete and suggested handling
Windows signal dispatch in the interrupt handlers, then factoring that
with ProcessProcSignalBarrier():
https://www.postgresql.org/message-id/20230111204836.rqzzbcufc7gziidx%40awork3.anarazel.de
https://www.postgresql.org/message-id/20230112004014.yygcctvdyomrreup%40awork3.anarazel.de

These results suggest that both proposals fix this reproducer, with v2
closer to the earlier review direction. The old thread stopped before
the suggested helper refactor and its CommitFest entry was withdrawn.
Would it be useful for me to refresh v2 and explore that helper on
current master, or is there a preferred design now?

Best,
Harrison