| 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
| 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 |