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

Hello Fujii-san,

16.09.2026 13:30, Fujii Masao wrote:
> On Mon, Sep 7, 2026 at 1:34 AM Ayush Tiwari<ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>> 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?
> LGTM. So barring any objections, I will commit the patches.

It looks like skink asks for the fix, e.g. as below [3]:
 69/325 recovery - postgresql:recovery/031_recovery_conflict ERROR           1013.92s   (exit status 255 or 0xff)

[11:14:59.084](0.080s) ok 14 - startup deadlock: lock acquisition is waiting
Waiting for replication conn standby's replay_lsn to pass 0/3461410 on primary
done
timed out waiting for match: (?^:User transaction caused buffer deadlock with recovery.) at
/home/bf/bf-build/skink/REL_17_STABLE/pgsql/src/test/recovery/t/031_recovery_conflict.pl line 318.

This is a new failure mode, but it's still caused by autovacuum, as far as
I can see.

I've reproduced this locally when running 20 tests in parallel, in a VM
with 10% CPU limit.
16      [10:21:35] t/031_recovery_conflict.pl ..
16      Dubious, test returned 255 (wstat 65280, 0xff00)
16      All 14 subtests passed
16      [10:21:35]
16
16      Test Summary Report
16      -------------------
16      t/031_recovery_conflict.pl (Wstat: 65280 (exited 255) Tests: 14 Failed: 0)
16        Non-zero exit status: 255
16        Parse errors: No plan found in TAP output
16      Files=1, Tests=14, 510 wallclock secs ( 0.06 usr  0.05 sys +  2.28 cusr 18.31 csys = 20.70 CPU)
16      Result: FAIL
16      # Tests were run but no plan was declared and done_testing() was not seen.
16      # Looks like your test exited with 255 just after 14.
16      make: *** [Makefile:28: check] Error 1

With  log_autovacuum_min_duration = 0:
/031_recovery_conflict_primary.log:
2026-10-01 10:17:23.078 UTC [193321][client backend][4/8:0] LOG: statement: BEGIN;
2026-10-01 10:17:23.255 UTC [193321][client backend][4/8:0] LOG: statement: INSERT INTO test_recovery_conflict_table1(a)
SELECT generate_series(1, 100) i;
2026-10-01 10:17:23.364 UTC [193321][client backend][4/8:767] LOG: statement: ROLLBACK;
...
2026-10-01 10:17:27.804 UTC [193405][autovacuum worker][11/7:0] LOG:  automatic vacuum of table
"test_db.public.test_recovery_conflict_table1": index scans: 0
        pages: 0 removed, 1 remain, 1 scanned (100.00% of total), 0 eagerly scanned
        tuples: 100 removed, 2 remain, 0 are dead but not yet removable
...
2026-10-01 10:17:33.901 UTC [193477][client backend][7/5:0] LOG: connection authorized: user=vagrant database=test_db
application_name=031_recovery_conflict.pl
2026-10-01 10:17:36.171 UTC [193477][client backend][7/6:0] LOG: statement: VACUUM FREEZE test_recovery_conflict_table1;
2026-10-01 10:17:36.996 UTC [193477][client backend][:0] LOG: disconnection: session time: 0:00:03.096 user=vagrant
database=test_db host=[local]
...

As a result, there is no "WAL redo at X/XXXX for Heap2/PRUNE_VACUUM_SCAN"
after 10:17:36 and "User transaction caused buffer deadlock with recovery"
in 031_recovery_conflict_standby.log.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-09-28%2023%3A37%3A34
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-09-29%2010%3A39%3A34
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2026-09-30%2008%3A38%3A16

Best regards,
Alexander