Hi, On Fri, 4 Sept 2026 at 07:56, Ayush Tiwari <[email protected]> wrote: > > On Fri, 4 Sept 2026 at 09:30, Alexander Lakhin <[email protected]> wrote: > > > > Hello Ayush and Fujii-san, > > > > 04.09.2026 06:07, Fujii Masao wrote: > > > On Fri, Sep 4, 2026 at 6:48 AM Ayush Tiwari <[email protected]> > > > wrote: > > >> Thoughts? > > > Thanks for the patches! They look good to me. > > > > Thank you for paying attention to my reports! > > > > I'm not sure about the autovacuum fix -- I've found that I tried the same > > targeted autovacuum = false as Melanie proposed back then ([1]) and the > > test still failed. Please let me recheck carefully if it's still an issue. > > > > Regarding v1-0001, I've tested it with the repro.patch applied and > > confirmed it works. Thank you! > > > > [1] > > https://www.postgresql.org/message-id/714729ea-f536-0faf-353b-cbd5c8f241ea%40gmail.com > > Thanks for testing and confirming 0001.
I confirm that the bug is reproducible with repro.patch and 0001 fixes it. > One detail I noticed in [1] is that the posted change sets > autovacuum_enabled=false on the initial table. That table is later dropped > and recreated for the recovery deadlock test, so the reloption does not > carry over. 0002 sets it on the recreated table instead. I generated the attached reproducer with help from an LLM, and I confirm that your 0002 fixes the problem and Alexander's change on the [1] fails because of the reason you mentioned. Both patches LGTM. -- Regards, Nazir Bilal Yavuz Microsoft
From 3ee57705135221556e76b96968f1d517ad2cd1d3 Mon Sep 17 00:00:00 2001 From: Nazir Bilal Yavuz <[email protected]> Date: Fri, 4 Sep 2026 11:33:29 +0300 Subject: [PATCH] Repro 031_recovery_conflict.pl autovacuum --- src/test/recovery/t/031_recovery_conflict.pl | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/test/recovery/t/031_recovery_conflict.pl b/src/test/recovery/t/031_recovery_conflict.pl index c87acd20e0a..da08d2d9a2c 100644 --- a/src/test/recovery/t/031_recovery_conflict.pl +++ b/src/test/recovery/t/031_recovery_conflict.pl @@ -34,6 +34,15 @@ temp_tablespaces = $tablespace1 # nice to get some minimal coverage of that code. log_recovery_conflict_waits = on deadlock_timeout = 10ms + +# REPRO: on a slow/loaded machine the autovacuum launcher gets a chance to +# process the test tables in the middle of the test. Waking the launcher up +# more often just makes that reliably reproducible, it does not otherwise +# change what autovacuum does here: the rolled back INSERT below leaves 100 +# dead tuples behind, which is already above the default +# autovacuum_vacuum_threshold. +autovacuum_naptime = 1s +log_autovacuum_min_duration = 0 ]); $node_primary->start; @@ -257,6 +266,14 @@ ok(1, "$sect: cursor holding conflicting pin, also waiting for lock, established" ); +# REPRO: emulate a slow machine by stalling here, giving the autovacuum +# launcher (naptime = 1s) several chances to process $table1 while the standby +# session holds the pin and waits for the lock. This deliberately does not +# wait for autovacuum to actually process the table, so it stays a valid +# detector once a fix keeps autovacuum away from $table1. +sleep(5); +$node_primary->wait_for_replay_catchup($node_standby); + # just to make sure we're waiting for lock already ok( $node_standby->poll_query_until( 'postgres', qq[ -- 2.47.3
