Re: Stabilize recovery conflict stats checks in 031_recovery_conflict.pl

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stabilize recovery conflict stats checks in 031_recovery_conflict.pl
Date: 2026-09-06 08:00:00
Message-ID: addb4281-5ffb-41f1-b28e-e68e51502eb0@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-09-06 09:04:01 Re: Add ssl_(supported|shared)_groups to sslinfo
Previous Message Xuneng Zhou 2026-09-06 04:03:20 Re: Implement waiting for wal lsn replay: reloaded