Skip to content

Commit 0174c2d

Browse files
committed
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
1 parent 0da096d commit 0174c2d

File tree

1 file changed

+7
-7
lines changed

1 file changed

+7
-7
lines changed

src/test/recovery/t/031_recovery_conflict.pl

+7-7
Original file line numberDiff line numberDiff line change
@@ -109,8 +109,8 @@
109109
# to check the log starting now for recovery conflict messages
110110
my $log_location = -s $node_standby->logfile;
111111

112-
# VACUUM on the primary
113-
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
112+
# VACUUM FREEZE on the primary
113+
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
114114

115115
# Wait for catchup. Existing connection will be terminated before replay is
116116
# finished, so waiting for catchup ensures that there is no race between
@@ -144,8 +144,8 @@
144144
$node_primary->safe_psql($test_db,
145145
qq[UPDATE $table1 SET a = a + 1 WHERE a > 2;]);
146146

147-
# VACUUM, pruning those dead tuples
148-
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
147+
# VACUUM FREEZE, pruning those dead tuples
148+
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
149149

150150
# Wait for attempted replay of PRUNE records
151151
$node_primary->wait_for_replay_catchup($node_standby);
@@ -264,9 +264,9 @@
264264
], 'waiting'),
265265
"$sect: lock acquisition is waiting");
266266

267-
# VACUUM will prune away rows, causing a buffer pin conflict, while standby
268-
# psql is waiting on lock
269-
$node_primary->safe_psql($test_db, qq[VACUUM $table1;]);
267+
# VACUUM FREEZE will prune away rows, causing a buffer pin conflict, while
268+
# standby psql is waiting on lock
269+
$node_primary->safe_psql($test_db, qq[VACUUM FREEZE $table1;]);
270270
$node_primary->wait_for_replay_catchup($node_standby);
271271

272272
check_conflict_log("User transaction caused buffer deadlock with recovery.");

0 commit comments

Comments
 (0)