Fix instability in 031_recovery_conflict.pl.

Where the test wants a VACUUM command to generate WAL that would
conflict with a session on the standby, it could transiently fail to do
so if it couldn't acquire a cleanup lock conditionally at that moment on
the primary.  VACUUM FREEZE will wait, so use that instead.

No back-patch for now, but that will be needed if/when the test is
re-enabled in back-branches.

Suggested-by: Andres Freund <andres@anarazel.de>
Reported-by: Christoph Berg <myon@debian.org>
Discussion: https://postgr.es/m/20230812210006.ei7tutzwcr5svyt6%40awork3.anarazel.de
This commit is contained in:
Thomas Munro 2023-09-07 14:38:15 +12:00
parent 0da096d78e
commit 0174c2d213
1 changed files with 7 additions and 7 deletions

View File

@ -109,8 +109,8 @@ like($res, qr/^0$/m, "$sect: cursor with conflicting pin established");
# to check the log starting now for recovery conflict messages
my $log_location = -s $node_standby->logfile;
# VACUUM on the primary
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
# VACUUM FREEZE on the primary
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
# Wait for catchup. Existing connection will be terminated before replay is
# finished, so waiting for catchup ensures that there is no race between
@ -144,8 +144,8 @@ like($res, qr/^0$/m, "$sect: cursor with conflicting snapshot established");
$node_primary->safe_psql($test_db,
qq[UPDATE $table1 SET a = a + 1 WHERE a > 2;]);
# VACUUM, pruning those dead tuples
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
# VACUUM FREEZE, pruning those dead tuples
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
# Wait for attempted replay of PRUNE records
$node_primary->wait_for_replay_catchup($node_standby);
@ -264,9 +264,9 @@ SELECT 'waiting' FROM pg_locks WHERE locktype = 'relation' AND NOT granted;
], 'waiting'),
"$sect: lock acquisition is waiting");
# VACUUM will prune away rows, causing a buffer pin conflict, while standby
# psql is waiting on lock
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
# VACUUM FREEZE will prune away rows, causing a buffer pin conflict, while
# standby psql is waiting on lock
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
$node_primary->wait_for_replay_catchup($node_standby);
check_conflict_log("User transaction caused buffer deadlock with recovery.");