| From: | Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: client_connection_check_interval default value |
| Date: | 2026-03-09 18:18:05 |
| Message-ID: | CAB5wL7ZaQ3bTT+Db2R0s_RyQhk6ikFRn3TqjCodrL7wznATaqg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, 9 Mar 2026 Pzt, 15:12 tarihinde şunu
yazdı:
> 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.
>
>
+1 to this idea. It would be a better approach in the future if we need to
change the behaviour of emitting logs about these topics.
I do see the trade-off. Put simply with only one message, we can lose
visibility into long lock waits. But I think that's a separate concern. If
there's a real need for periodic "still waiting" messages in the future, we
could introduce a dedicated GUC (something like log_lock_waits_interval) or
even a simple constant to control that independently of
client_connection_check_interval. That way deadlock detection, connection
checking, and lock-wait logging each have their own rules and don't
interfere with each other.
Regards.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-03-09 18:25:25 | Re: Speed up COPY FROM text/CSV parsing using SIMD |
| Previous Message | Andrey Borodin | 2026-03-09 17:07:59 | Re: Compression of bigger WAL records |