04.09.2026 19:00, Alexander Lakhin wrote:
Yes, I've tested both on my side -- no single run (of thousands) failed.
Also checked with LLM all the failures of 031_recovery_conflict registered
on wiki -- they all should be ruled out now.
Having tried a bit harder (running the test on a relatively slow riscv64
device), I've discovered one more instability. It can be reproduced
reliably on an ordinary machine with:
/tmp/temp.config
autovacuum_naptime = 1
autovacuum_analyze_threshold = 1
--- a/src/backend/commands/analyze.c
+++ b/src/backend/commands/analyze.c
@@ -132,4 +132,5 @@ analyze_rel(Oid relid, RangeVar *relation,
CHECK_FOR_INTERRUPTS();
+if (AmAutoVacuumWorkerProcess()) pg_usleep(1000000);
/*
* Open the relation, getting ShareUpdateExclusiveLock to ensure that two
--- a/src/test/recovery/t/031_recovery_conflict.pl
+++ b/src/test/recovery/t/031_recovery_conflict.pl
@@ -132,4 +132,5 @@ $node_primary->safe_psql($test_db,
$node_primary->wait_for_replay_catchup($node_standby);
+sleep(1);
# DECLARE and FETCH from cursor on the standby
$res = $psql_standby->query_safe(
TEMP_CONFIG=/tmp/temp.config make -s check -C src/test/recovery
PROVE_TESTS="t/031*"
t/031_recovery_conflict.pl .. 4/? # die: timed out waiting for file
.../src/test/recovery/tmp_check/log/031_recovery_conflict_standby.log contents to match: (?^:User query might have
needed to see row versions that must be removed) at t/031_recovery_conflict.pl line 324.
# Looks like your test exited with 255 just after 4.
t/031_recovery_conflict.pl .. Dubious, test returned 255 (wstat 65280, 0xff00)
All 4 subtests passed
Test Summary Report
-------------------
t/031_recovery_conflict.pl (Wstat: 65280 (exited 255) Tests: 4 Failed: 0)
Non-zero exit status: 255
Files=1, Tests=4, 183 wallclock secs ( 0.00 usr 0.00 sys + 0.17 cusr 0.24
csys = 0.41 CPU)
(Originally, the test failed for me without extra autovacuum-related
settings and sleeps.)
Best regards,
Alexander
