On Tue, Mar 10, 2026 at 10:42 AM Chao Li <[email protected]> wrote: > > > > > On Mar 9, 2026, at 22:12, Fujii Masao <[email protected]> wrote: > > > > On Mon, Mar 9, 2026 at 6:03 PM Hüseyin Demir <[email protected]> wrote: > >> > >> Hi Fujii, > >> > >> Thanks for the patch. The rate-limiting approach makes sense to me. A > >> couple of thoughts: > >> > >> 1) I think Chao Li's suggestion of using max(10s, deadlock_timeout) as the > >> rate limit interval is worth adopting. If someone has set deadlock_timeout > >> to, say, 30s or 60s, they've already signaled they don't need frequent > >> lock-wait feedback. Logging every 10s after a 60s deadlock_timeout feels > >> inconsistent with that intent. > > > > Or perhaps they expect the log message to be emitted only once, > > just after deadlock_timeout, similar to the current behavior when > > client_connection_check_interval is not set, I guess. > > > > I'm now starting thinking it might be better to preserve the existing > > behavior (emitting the message once per wait) regardless of whether > > client_connection_check_interval is set, and implement that first. > > > > If there is a need to emit the message periodically, we could add that > > as a separate feature later so that it works independently of > > the client_connection_check_interval setting. > > > > Thought? > > Yeah, IMHO, preserving the existing behavior is preferable. Logically, > client_connection_check_interval and log_lock_waitsbelong to two different > departments. Even though they cross paths at the implementation level today, > having the behavior of log_lock_waits change just because > client_connection_check_interval is adjusted seems surprising.
So, attached is a patch that ensures the "still waiting on lock" message is reported at most once during a lock wait, even if the wait is interrupted. Regards, -- Fujii Masao
v2-0001-Ensure-still-waiting-on-lock-message-is-logged-on.patch
Description: Binary data
