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

Hi,

On Fri, 4 Sept 2026 at 00:30, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> Hello Ayush, Nazir, and Fujii-san,
>
> 03.09.2026 07:19, Fujii Masao wrote:
>
> Thanks Ayush and Nazir, for the test and review! I've pushed the patch.
>
>
> Thank you for fixing the test!
> I've been tracking this failure at:
>
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#031_recovery_conflict.pl_test_might_fail_due_to_late_pgstat_entries_flushing
>
> Probably you would also find worth fixing two other issues in the same
test:
>
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#031_recovery_conflict.pl_fails_to_detect_an_expected_lock_acquisition
>
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#031_recovery_conflict.pl_fails_when_a_conflict_counted_twice
>
> Both failures were produced not long ago: [1], [2].
>
> [1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2026-07-07%2010%3A03%3A33
> [2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=adder&dt=2026-08-20%2000%3A50%3A11

Thanks a lot for the buildfarm links and logs!

I looked into the failures, and ISTM the exact stats checks are the main
problem. The startup process can signal the same backend more than once
while it is handling a recovery-conflict FATAL, so a counter can advance
from 0 to 2 and leave the test waiting for 1 indefinitely. Patch 0001
changes the per-conflict checks to > 0 and checks that
pg_stat_database.conflicts is at least the expected total. I think that
should fix the stats-polling failure.

I'm less certain about the autovacuum part, so I kept it in a separate
patch. Autovacuum could prune the dead tuples before the explicit VACUUM
FREEZE emits the WAL needed by the recovery deadlock test. Patch 0002
disables autovacuum only on the recreated table. Does that seem like the
right scope? Although split for review, I think both patches should be
applied together.

Thoughts?

Regards,
Ayush