MIME-Version: 1.0
References: <20260204213032.15bab46b@ardentperf.com>
 <CAHGQGwH7c5X4OkPaQ6VDaLGoFgJgwf_-HNwUi2uXoiAhkFkkyA@mail.gmail.com>
 <177304694613.1094603.10800724073727441272.pgcf@coridan.postgresql.org>
 <CAHGQGwG_Ud-N1zrULv8fE51-CUd2ZF3eDe7jUdNOm-rt_JgcQQ@mail.gmail.com>
 <017AD77A-21B6-4B0A-8847-207914D53CE0@gmail.com>
In-Reply-To: <017AD77A-21B6-4B0A-8847-207914D53CE0@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Fri, 13 Mar 2026 21:36:16 +0900
Message-ID: 
 <CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA@mail.gmail.com>
Subject: Re: client_connection_check_interval default value
To: Chao Li <li.evan.chao@gmail.com>
Cc: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="0000000000004a73fe064ce71e45"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwEBvWXU4sdu2DMxaUWdPYQvGesr1VPyX-WnSxtW9nN6UA%40mail.gmail.com>
Precedence: bulk

--0000000000004a73fe064ce71e45
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 10, 2026 at 10:42=E2=80=AFAM Chao Li <li.evan.chao@gmail.com> w=
rote:
>
>
>
> > On Mar 9, 2026, at 22:12, Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > On Mon, Mar 9, 2026 at 6:03=E2=80=AFPM H=C3=BCseyin Demir <huseyin.d3r@=
gmail.com> wrote:
> >>
> >> 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_tim=
eout 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 i=
nconsistent with that intent.
> >
> > 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.
> >
> > Thought?
>
> Yeah, IMHO, preserving the existing behavior is preferable. Logically, cl=
ient_connection_check_interval and log_lock_waitsbelong to two different de=
partments. Even though they cross paths at the implementation level today, =
having the behavior of log_lock_waits change just because client_connection=
_check_interval is adjusted seems surprising.

So, attached is a patch that ensures the "still waiting on lock" message is
reported at most once during a lock wait, even if the wait is interrupted.

Regards,

--=20
Fujii Masao

--0000000000004a73fe064ce71e45
Content-Type: application/octet-stream;
	name="v2-0001-Ensure-still-waiting-on-lock-message-is-logged-on.patch"
Content-Disposition: attachment;
	filename="v2-0001-Ensure-still-waiting-on-lock-message-is-logged-on.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mmovro060>
X-Attachment-Id: f_mmovro060

RnJvbSBhM2RjYmJlZjM3NGUyNGFiODk1ZTUwMDU5Y2Y0MGZhOGE2MzU4ZGZhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBGdWppaSBNYXNhbyA8ZnVqaWlAcG9zdGdyZXNxbC5vcmc+CkRh
dGU6IEZyaSwgMTMgTWFyIDIwMjYgMTQ6Mzc6NDMgKzA5MDAKU3ViamVjdDogW1BBVENIIHYyXSBF
bnN1cmUgInN0aWxsIHdhaXRpbmcgb24gbG9jayIgbWVzc2FnZSBpcyBsb2dnZWQgb25seSBvbmNl
CiBwZXIgd2FpdC4KCldoZW4gbG9nX2xvY2tfd2FpdHMgaXMgZW5hYmxlZCwgdGhlICJzdGlsbCB3
YWl0aW5nIG9uIGxvY2siIG1lc3NhZ2UgaXMgbm9ybWFsbHkKZW1pdHRlZCBvbmx5IG9uY2Ugd2hp
bGUgYSBzZXNzaW9uIGNvbnRpbnVlcyB3YWl0aW5nLiBIb3dldmVyLCBpZiB0aGUgd2FpdCBpcwpp
bnRlcnJ1cHRlZCwgZm9yIGV4YW1wbGUgYnkgd2FrZXVwcyBmcm9tIGNsaWVudF9jb25uZWN0aW9u
X2NoZWNrX2ludGVydmFsLApTSUdIVVAgZm9yIGNvbmZpZ3VyYXRpb24gcmVsb2Fkcywgb3Igc2lt
aWxhciBldmVudHMsIHRoZSBtZXNzYWdlIGNvdWxkIGJlCmVtaXR0ZWQgYWdhaW4gZWFjaCB0aW1l
IHRoZSB3YWl0IHJlc3VtZXMuCgpGb3IgZXhhbXBsZSwgd2l0aCB2ZXJ5IHNtYWxsIGNsaWVudF9j
b25uZWN0aW9uX2NoZWNrX2ludGVydmFsIHZhbHVlcwooZS5nLiwgMTAwIG1zKSwgdGhpcyBiZWhh
dmlvciBjb3VsZCBmbG9vZCB0aGUgbG9ncyB3aXRoIHJlcGVhdGVkIG1lc3NhZ2VzLAptYWtpbmcg
dGhlbSBkaWZmaWN1bHQgdG8gdXNlLgoKVG8gcHJldmVudCB0aGlzLCB0aGlzIGNvbW1pdCBndWFy
ZHMgdGhlICJzdGlsbCB3YWl0aW5nIG9uIGxvY2siIG1lc3NhZ2Ugc28KaXQgaXMgcmVwb3J0ZWQg
YXQgbW9zdCBvbmNlIGR1cmluZyBhIGxvY2sgd2FpdCwgZXZlbiBpZiB0aGUgd2FpdCBpcyBpbnRl
cnJ1cHRlZC4KVGhpcyBwcmVzZXJ2ZXMgdGhlIGludGVuZGVkIGJlaGF2aW9yIHdoZW4gbm8gaW50
ZXJydXB0cyBvY2N1ci4KLS0tCiBzcmMvYmFja2VuZC9zdG9yYWdlL2xtZ3IvcHJvYy5jIHwgMzAg
KysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjQgaW5zZXJ0
aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9zdG9yYWdl
L2xtZ3IvcHJvYy5jIGIvc3JjL2JhY2tlbmQvc3RvcmFnZS9sbWdyL3Byb2MuYwppbmRleCBkNDA3
NzI1ZTYwMi4uNWZiYzBkZmIxOTggMTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1n
ci9wcm9jLmMKKysrIGIvc3JjL2JhY2tlbmQvc3RvcmFnZS9sbWdyL3Byb2MuYwpAQCAtMTMwOSw2
ICsxMzA5LDcgQEAgUHJvY1NsZWVwKExPQ0FMTE9DSyAqbG9jYWxsb2NrKQogCVRpbWVzdGFtcFR6
IHN0YW5kYnlXYWl0U3RhcnQgPSAwOwogCWJvb2wJCWFsbG93X2F1dG92YWN1dW1fY2FuY2VsID0g
dHJ1ZTsKIAlib29sCQlsb2dnZWRfcmVjb3ZlcnlfY29uZmxpY3QgPSBmYWxzZTsKKwlib29sCQls
b2dnZWRfbG9ja193YWl0cyA9IGZhbHNlOwogCVByb2NXYWl0U3RhdHVzIG15V2FpdFN0YXR1czsK
IAlEZWFkTG9ja1N0YXRlIGRlYWRsb2NrX3N0YXRlOwogCkBAIC0xNjA2LDEyICsxNjA3LDI5IEBA
IFByb2NTbGVlcChMT0NBTExPQ0sgKmxvY2FsbG9jaykKIAkJCX0KIAogCQkJaWYgKG15V2FpdFN0
YXR1cyA9PSBQUk9DX1dBSVRfU1RBVFVTX1dBSVRJTkcpCi0JCQkJZXJlcG9ydChMT0csCi0JCQkJ
CQkoZXJybXNnKCJwcm9jZXNzICVkIHN0aWxsIHdhaXRpbmcgZm9yICVzIG9uICVzIGFmdGVyICVs
ZC4lMDNkIG1zIiwKLQkJCQkJCQkJTXlQcm9jUGlkLCBtb2RlbmFtZSwgYnVmLmRhdGEsIG1zZWNz
LCB1c2VjcyksCi0JCQkJCQkgKGVycmRldGFpbF9sb2dfcGx1cmFsKCJQcm9jZXNzIGhvbGRpbmcg
dGhlIGxvY2s6ICVzLiBXYWl0IHF1ZXVlOiAlcy4iLAotCQkJCQkJCQkJCQkgICAiUHJvY2Vzc2Vz
IGhvbGRpbmcgdGhlIGxvY2s6ICVzLiBXYWl0IHF1ZXVlOiAlcy4iLAotCQkJCQkJCQkJCQkgICBs
b2NrSG9sZGVyc051bSwgbG9ja19ob2xkZXJzX3NidWYuZGF0YSwgbG9ja193YWl0ZXJzX3NidWYu
ZGF0YSkpKSk7CisJCQl7CisJCQkJLyoKKwkJCQkgKiBHdWFyZCB0aGUgInN0aWxsIHdhaXRpbmcg
b24gbG9jayIgbG9nIG1lc3NhZ2Ugc28gaXQgaXMKKwkJCQkgKiByZXBvcnRlZCBhdCBtb3N0IG9u
Y2Ugd2hpbGUgd2FpdGluZyBmb3IgdGhlIGxvY2suCisJCQkJICoKKwkJCQkgKiBXaXRob3V0IHRo
aXMgZ3VhcmQsIHRoZSBtZXNzYWdlIGNhbiBiZSBlbWl0dGVkIHdoZW5ldmVyIHRoZQorCQkJCSAq
IGxvY2std2FpdCBzbGVlcCBpcyBpbnRlcnJ1cHRlZCAoZm9yIGV4YW1wbGUgYnkgU0lHSFVQIGZv
cgorCQkJCSAqIGNvbmZpZyByZWxvYWQgb3IgYnkgY2xpZW50X2Nvbm5lY3Rpb25fY2hlY2tfaW50
ZXJ2YWwpLiBGb3IKKwkJCQkgKiBleGFtcGxlLCBpZiBjbGllbnRfY29ubmVjdGlvbl9jaGVja19p
bnRlcnZhbCBpcyBzZXQgdmVyeQorCQkJCSAqIGxvdyAoZS5nLiwgMTAwIG1zKSwgdGhlIG1lc3Nh
Z2UgY291bGQgYmUgbG9nZ2VkIHJlcGVhdGVkbHksCisJCQkJICogZmxvb2RpbmcgdGhlIGxvZyBh
bmQgbWFraW5nIGl0IGRpZmZpY3VsdCB0byB1c2UuCisJCQkJICovCisJCQkJaWYgKCFsb2dnZWRf
bG9ja193YWl0cykKKwkJCQl7CisJCQkJCWVyZXBvcnQoTE9HLAorCQkJCQkJCShlcnJtc2coInBy
b2Nlc3MgJWQgc3RpbGwgd2FpdGluZyBmb3IgJXMgb24gJXMgYWZ0ZXIgJWxkLiUwM2QgbXMiLAor
CQkJCQkJCQkJTXlQcm9jUGlkLCBtb2RlbmFtZSwgYnVmLmRhdGEsIG1zZWNzLCB1c2VjcyksCisJ
CQkJCQkJIChlcnJkZXRhaWxfbG9nX3BsdXJhbCgiUHJvY2VzcyBob2xkaW5nIHRoZSBsb2NrOiAl
cy4gV2FpdCBxdWV1ZTogJXMuIiwKKwkJCQkJCQkJCQkJCSAgICJQcm9jZXNzZXMgaG9sZGluZyB0
aGUgbG9jazogJXMuIFdhaXQgcXVldWU6ICVzLiIsCisJCQkJCQkJCQkJCQkgICBsb2NrSG9sZGVy
c051bSwgbG9ja19ob2xkZXJzX3NidWYuZGF0YSwgbG9ja193YWl0ZXJzX3NidWYuZGF0YSkpKSk7
CisJCQkJCWxvZ2dlZF9sb2NrX3dhaXRzID0gdHJ1ZTsKKwkJCQl9CisJCQl9CiAJCQllbHNlIGlm
IChteVdhaXRTdGF0dXMgPT0gUFJPQ19XQUlUX1NUQVRVU19PSykKIAkJCQllcmVwb3J0KExPRywK
IAkJCQkJCShlcnJtc2coInByb2Nlc3MgJWQgYWNxdWlyZWQgJXMgb24gJXMgYWZ0ZXIgJWxkLiUw
M2QgbXMiLAotLSAKMi41MS4yCgo=
--0000000000004a73fe064ce71e45--