Re: client_connection_check_interval default value

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,

In response to

Responses

Browse pgsql-hackers by date

  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