From 3ee57705135221556e76b96968f1d517ad2cd1d3 Mon Sep 17 00:00:00 2001 From: Nazir Bilal Yavuz Date: Fri, 4 Sep 2026 11:33:29 +0300 Subject: [PATCH] Repro 031_recovery_conflict.pl autovacuum --- src/test/recovery/t/031_recovery_conflict.pl | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/test/recovery/t/031_recovery_conflict.pl b/src/test/recovery/t/031_recovery_conflict.pl index c87acd20e0a..da08d2d9a2c 100644 --- a/src/test/recovery/t/031_recovery_conflict.pl +++ b/src/test/recovery/t/031_recovery_conflict.pl @@ -34,6 +34,15 @@ temp_tablespaces = $tablespace1 # nice to get some minimal coverage of that code. log_recovery_conflict_waits = on deadlock_timeout = 10ms + +# REPRO: on a slow/loaded machine the autovacuum launcher gets a chance to +# process the test tables in the middle of the test. Waking the launcher up +# more often just makes that reliably reproducible, it does not otherwise +# change what autovacuum does here: the rolled back INSERT below leaves 100 +# dead tuples behind, which is already above the default +# autovacuum_vacuum_threshold. +autovacuum_naptime = 1s +log_autovacuum_min_duration = 0 ]); $node_primary->start; @@ -257,6 +266,14 @@ ok(1, "$sect: cursor holding conflicting pin, also waiting for lock, established" ); +# REPRO: emulate a slow machine by stalling here, giving the autovacuum +# launcher (naptime = 1s) several chances to process $table1 while the standby +# session holds the pin and waits for the lock. This deliberately does not +# wait for autovacuum to actually process the table, so it stays a valid +# detector once a fix keeps autovacuum away from $table1. +sleep(5); +$node_primary->wait_for_replay_catchup($node_standby); + # just to make sure we're waiting for lock already ok( $node_standby->poll_query_until( 'postgres', qq[ -- 2.47.3