Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

Hi,

On 2022-06-21 17:22:05 +1200, Thomas Munro wrote:
> Problem: I saw 031_recovery_conflict.pl time out while waiting for a
> buffer pin conflict, but so far once only, on CI:
>
> https://cirrus-ci.com/task/5956804860444672
>
> timed out waiting for match: (?^:User was holding shared buffer pin
> for too long) at t/031_recovery_conflict.pl line 367.
>
> Hrmph. Still trying to reproduce that, which may be a bug in this
> patch, a bug in the test or a pre-existing problem. Note that
> recovery didn't say something like:
>
> 2022-06-21 17:05:40.931 NZST [57674] LOG: recovery still waiting
> after 11.197 ms: recovery conflict on buffer pin
>
> (That's what I'd expect to see in
> https://api.cirrus-ci.com/v1/artifact/task/5956804860444672/log/src/test/recovery/tmp_check/log/031_recovery_conflict_standby.log
> if the startup process had decided to send the signal).
>
> ... so it seems like the problem in that run is upstream of the interrupt stuff.

Odd. The only theory I have so far is that the manual vacuum on the primary
somehow decided to skip the page, and thus didn't trigger a conflict. Because
clearly replay progressed past the records of the VACUUM. Perhaps we should
use VACUUM VERBOSE? In contrast to pg_regress tests that should be
unproblematic?

Greetings,

Andres Freund