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.
