Re: failures in t/031_recovery_conflict.pl on CI

Hi,

On 2022-05-02 23:44:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I ended up committing the extension of the test first, before the fix. I think
> > that's the cause of the failure on longfin on serinus. Let's hope the
> > situation improves with the now also committed (and backpatched) fix.
>
> longfin's definitely not very happy: four out of six tries have ended with

Too bad :(

> psql:<stdin>:8: ERROR: canceling statement due to conflict with recovery
> LINE 1: SELECT * FROM test_recovery_conflict_table2;
> ^
> DETAIL: User was holding shared buffer pin for too long.
> timed out waiting for match: (?^:User transaction caused buffer deadlock with recovery.) at t/031_recovery_conflict.pl line 358.
>
>
> I can poke into that tomorrow, but are you sure that that isn't an
> expectable result?

It's not expected. But I think I might see what the problem is:

$psql_standby{stdin} .= qq[
BEGIN;
-- hold pin
DECLARE $cursor1 CURSOR FOR SELECT a FROM $table1;
FETCH FORWARD FROM $cursor1;
-- wait for lock held by prepared transaction
SELECT * FROM $table2;
];
ok( pump_until(
$psql_standby{run}, $psql_timeout,
\$psql_standby{stdout}, qr/^1$/m,),
"$sect: cursor holding conflicting pin, also waiting for lock, established"
);

We wait for the FETCH (and thus the buffer pin to be acquired). But that
doesn't guarantee that the lock has been acquired. We can't check that with
pump_until() afaics, because there'll not be any output. But a query_until()
checking pg_locks should do the trick?

Greetings,

Andres Freund