> On Feb 18, 2026, at 13:30, Fujii Masao <[email protected]> wrote:
>
> On Fri, Feb 6, 2026 at 9:01 AM Tom Lane <[email protected]> wrote:
>>> The issue is that backends blocked in ProcSleep() are woken up every
>>> client_connection_check_interval and may emit a "still waiting" message
>>> each time if log_lock_waits is enabled. To mitigate this, just one idea is
>>> to add a flag to track whether the "still waiting" message has already been
>>> emitted during a call to ProcSleep(), and suppress further messages
>>> once it has been logged.
>>
>> Independently of what's the default, it seems like it'd be valuable to
>> make that interaction better. I think it is reasonable to keep on
>> emitting "still waiting" every so often, but we could probably
>> rate-limit that to a lot less than every 2 seconds.
>
> Attached is a patch that rate-limits the "still waiting on lock" message
> to at most once every 10s.
>
> I chose 10s instead of the suggested 2s, since 2s felt too short. But we can
> discuss the appropriate interval and adjust it if needed. The value is
> currently hard-coded, as making it configurable does not seem necessary.
>
> Thoughts?
>
> --
> Fujii Masao
> <v1-0001-Rate-limit-repeated-still-waiting-on-lock-log-mes.patch>
I feel 10 seconds is good.
The other thinking is that, the message will only be printed after the first
deadlock check is fired. So, if someone sets deadlock_timeout to a large value,
say 30 or 60 seconds, then any waiting log would already be very delayed. In
that case, the user might not want to log more often than deadlock checks
anyway. From this perspective, the rate limit timeout could be max(10s,
deadlock_timeout). Anyway, this is not a strong opinion.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
