public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ilmar Yunusov <[email protected]>
To: [email protected]
Cc: JoongHyuk Shin <[email protected]>
Subject: Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
Date: Wed, 03 Jun 2026 10:22:19 +0000
Message-ID: <178048213946.1017.10427695804113210415.pgcf@coridan.postgresql.org> (raw)
In-Reply-To: <CACSdjfNicWdgiX9RDSWiAkUKhnpiEEG5__2SauvH5c+a8CEUKA@mail.gmail.com>
References: <CACSdjfO3ox8i8N3KxGf3HThzX1vnRRkY2kq1m5qsvGxjcuM1jg@mail.gmail.com>
<CACSdjfNicWdgiX9RDSWiAkUKhnpiEEG5__2SauvH5c+a8CEUKA@mail.gmail.com>
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, passed
Spec compliant: not tested
Documentation: not tested
Hi,
I looked at v3 again, this time on Linux, focusing on the repeated SIGUSR1
behavior and the log_recovery_conflict_waits timing issue I reported for v2.
I used the v3 attachment from JoongHyuk's 2026-06-03 message, on
origin/master at f2081a7800f1696cb0415bacd655cb41b7b9ca63.
The patch applies cleanly with git am, and git diff --check reports no
issues.
I built with:
./configure --prefix="$PWD/pg-install" --without-readline --without-zlib --without-icu --enable-tap-tests
make -s -j3
make -s install
That passed.
The new targeted TAP test passed:
make -C src/test/recovery check PROVE_TESTS=t/054_bufferpin_conflict_log_timing.pl
Result:
t/054_bufferpin_conflict_log_timing.pl .. ok
All tests successful.
Files=1, Tests=3
Result: PASS
I also ran the full recovery TAP suite:
make -C src/test/recovery check
That passed too:
All tests successful.
Files=53, Tests=633
Result: PASS
Six tests were skipped because injection points were not supported by this
build.
For the signal behavior, I ran the same buffer-pin conflict reproducer under
strace on the standby postmaster and its children:
strace -ff -qq -e trace=kill,tgkill,tkill
The count below is for kill/tgkill/tkill(..., SIGUSR1) syscalls during the
conflict window, after subtracting signals already seen before VACUUM FREEZE.
On unpatched master:
sigusr1_delta=51
recovery still waiting after 100.442 ms: recovery conflict on buffer pin
terminating connection due to conflict with recovery
recovery finished waiting after 5001.455 ms: recovery conflict on buffer pin
With v3:
sigusr1_delta=2
recovery still waiting after 100.479 ms: recovery conflict on buffer pin
terminating connection due to conflict with recovery
recovery finished waiting after 5001.778 ms: recovery conflict on buffer pin
I interpret the two v3 SIGUSR1 syscalls as the one deadlock-check signal and
the final cancellation signal at max_standby_streaming_delay. So in this
repro, v3 removes the repeated deadlock-check signals every deadlock_timeout,
while keeping the "recovery still waiting" log near deadlock_timeout.
I did not find a new issue in the checked path.
I have not reviewed the backpatching question, and I did not run
installcheck-world.
Regards,
Ilmar Yunusov
The new status of this patch is: Ready for Committer
view thread (11+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
In-Reply-To: <178048213946.1017.10427695804113210415.pgcf@coridan.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox