Re: Fix recovery conflict canceling the startup progress timeout

Hi Aidar, hackers,

Attached is v3. 0001 is Aidar’s fix (unchanged) and it applies cleanly
to REL_15_STABLE through master. 0002 replaces my v2-0002 test, which
was slow, Unix-only and timing-dependent.

Test-approach
═════════════

The new test uses a small Perl `restore_command',
`t/restore_on_gate_open', that won’t hand over a WAL segment while a
gate file for it exists. That holds the startup process just before the
conflicting record and holds it again just after it. The test waits on
wait events and the replay LSN instead of using sleeps or filtering
log-lines. Hence, it doesn’t depend on replay speed. On unfixed code
only the two “progress after conflict” checks fail, immediately.

As for test-runtime, v2-0002 took 031 from ~3s to 23s. v3-0002 now takes
it to ~6s. It passed on [my fork’s CI]
(<https://github.com/rtshkmr/postgres/actions/runs/42439674037>),
including Windows.

Red/green testing
═════════════════

Red/green tested on each branch, with 0001 reverted and applied:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
branch commit v3-0002*

────────────────────────────────────────────────────────────────────
master 0607aa61090 attached

REL_19 d60d7f4261d attached

REL_18 1da6ddbdc32 nocfbot variant: `BufferPin'

REL_17 e6b2f7c2b41 nocfbot variant: `BufferPin'

REL_16 e9c45974adb nocfbot variant: `BufferPin', helpers inlined

REL_15 21a53865fb5 nocfbot variant: `BufferPin', helpers inlined

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table 1: reproduction & fix-verification done; TAP-tested

The buffer-pin wait event was renamed in 19 (from `BufferPin' ->
`BufferCleanup'), and 15/16 don’t have `wait_for_event()' and
`advance_wal()' helpers. All of 031 is `skip_all' on 15/16, so I removed
that line locally to run those two. I’d suggest backpatching 0001 from
master through 15, and test to master through 17.

Related threads
═══════════════

1. CF 7372 reworks the same resolvers, and its v10 still ends them with
`disable_all_timeouts()'. If 7521 goes in first, 7372 needs to keep
the narrower cleanup when it rebases; v3-0002 fails if it doesn’t.

2. CF 6876 stops the progress timeout during standby-mode replay. This
bug and the test are about archive recovery, which 6876 doesn’t
touch.

Regards, Ritesh