> Okay, noted. Did you run some of the in-core TAP tests locally or did
> something else?
My initial repro was a custom tap test with a 2% failure rate, but
later I also got commit_ts/002_standby to reliably fail with a mostly
unmodified postgres: it needs wal_receiver_status_interval=0 and an
additional sleep. 300-500ms seems to work both on github actions and
on my pc, above that 002_standby can start failing differently
unrelated to the changes. In that case, the version with the required
fixes reverted still fails the same way as it did a few years ago, but
it also fails with all fixes applied, just differently.
I attached the patch for testing. The version I ran on github actions
is a bit more complex because of the additional debugging of the above
additional failure, but the idea is the same, and the github logs link
to the specific commit used there.
GitHub CI runs on my fork:
1000ms, proposed version failing differently:
https://github.com/dutow/postgres/actions/runs/38007567970
500ms: https://github.com/dutow/postgres/actions/runs/38008340610
300ms: https://github.com/dutow/postgres/actions/runs/38008343536
In all 3 runs master doesn't reproduce, proposed doesn't reproduce
(1000ms sleep version fails differently), proposed-nopeek (required
fix reverted) fails reliably, proposed-nopeek-nosleep (same, but no
sleep added) doesn't fail reliably.
