Hi, On Sun, 6 Sept 2026 at 13:30, Alexander Lakhin <[email protected]> wrote: > > 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
Thanks for the report. > --- 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.) Hmm, I think we can just disable the autovacuum completely. I revised 0002 to disable autovacuum for the test node instead. With your reproducer, the revised patch passes all 18 tests. The regular test passes as well. Thoughts? Regards, Ayush
v2-0001-Stabilize-recovery-conflict-count-checks.patch
Description: Binary data
v2-0002-Disable-autovacuum-in-recovery-conflict-test.patch
Description: Binary data
