A follow-up on the Windows side. v9 said I could not run that part
here; Nik pointed out off-list that a GitHub Actions runner does the
job, so I did the same thing he did in July: a throwaway branch on my
fork with v9 applied on 1a3e782e762 plus a small test module and a
workflow, run on windows-2022 (MSVC, meson, cassert).
The module is the one from my previous mail (publish
Extension/HarnessOuterWait, ereport(LOG), sleep). The workflow starts
a cluster per log destination, calls it from one session and samples
pg_stat_activity from another 3 s later, after ereport(LOG) has
returned, and fails the job unless every sample still shows the outer
event. It passed:
log_destination = eventlog Extension / HarnessOuterWait
stderr, logging_collector = off Extension / HarnessOuterWait
stderr, logging_collector = on Extension / HarnessOuterWait
The eventlog row did go through write_eventlog(): the workflow's last
step reads the Windows Application log back and fails unless the
harness line is there under the PostgreSQL source, and it found it:
2026-09-15 15:26:10.400 UTC [2232] LOG: harness: logging from
inside HarnessOuterWait
The stderr row is the write() fallback, as in July; stderr is
redirected on a runner, so WriteConsoleW() is still not exercised at
runtime.
Run: https://github.com/shinsj4653/postgres/actions/runs/34988125975
Branch: shinsj4653/postgres, ci/win-waitevents-v9 (fe909ac)
So the restore behaves the same on Windows, for the two portable paths
and for EventlogWrite. Nothing changes in the patches; this only fills
in the Windows column that was missing from v9.
