| From: | Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Subject: | Re: client_connection_check_interval default value |
| Date: | 2026-03-09 09:02:26 |
| Message-ID: | 177304694613.1094603.10800724073727441272.pgcf@coridan.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
2) The hardcoded 10s constant — could we define it as a named constant in a header file? That way it's easier to find and reason about if it ever needs to change.
3) Would it make sense to add a regression test for this? Something that verifies the rate limiting actually suppresses the repeated messages at the expected interval.
Regards,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2026-03-09 09:15:03 | Re: pg_buffercache: Add per-relation summary stats |
| Previous Message | yangyz | 2026-03-09 08:51:34 | Re: [PATCH] Remove trailing period from errmsg in subscriptioncmds.c |