Hi, On 2022-05-02 23:44:32 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.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