From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alfonso Escribano <alfonso.escribano@meteologica.com>
cc: pgsql-general@lists.postgresql.org
Subject: Re: Interaction between "client_connection_check_interval" and "log_lock_waits" parameters
In-reply-to: <92db4d94-f836-ff49-01e6-294ea7709d9d@meteologica.com>
References: <92db4d94-f836-ff49-01e6-294ea7709d9d@meteologica.com>
Comments: In-reply-to Alfonso Escribano <alfonso.escribano@meteologica.com>
	message dated "Wed, 03 Dec 2025 09:24:50 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <682526.1764783390.1@sss.pgh.pa.us>
Date: Wed, 03 Dec 2025 12:36:30 -0500
Message-ID: <682527.1764783390@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/682527.1764783390%40sss.pgh.pa.us>
Precedence: bulk

Alfonso Escribano <alfonso.escribano@meteologica.com> writes:
>     When client_connection_check_interval has any value, and
>     log_lock_waits is enabled, the postgresql log displays a message
>     about lock waits with the frequency of
>     client_connection_check_interval.

When log_lock_waits is enabled, we'll print that "still waiting"
message anytime ProcSleep is awoken from a wait-for-lock sleep,
if it's already waited deadlock_timeout or longer.  Normally there
isn't much that would awaken such a process other than being granted
the lock.  But here, you've set client_connection_check_interval
so short that that interrupt happens repeatedly while waiting.

Why in the world would you want client_connection_check_interval
as short as 10 ms?  Sane values would probably be more like 10 s.

			regards, tom lane