> 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.
nocfbot-0001-Repro-aid-widen-the-lost-FD_CLOSE-window-for-the-wal.patch
Description: Binary data
