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

Hi,

On Sun, 6 Sept 2026 at 13:30, Alexander Lakhin <exclusion(at)gmail(dot)com> 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