From: | Seino Yuki <seinoyu(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add “FOR UPDATE NOWAIT” lock details to the log. |
Date: | 2024-10-18 10:07:28 |
Message-ID: | 1d489ddfc9d2dc3622bbf866d32e1a45@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The choice between adding a new GUC or extending the existing one
> (e.g., log_lock_waits)
> is debatable, but I prefer the latter. I'm considering extending
> log_lock_waits
> to accept a value like "fail". If set to "on" (the current behavior),
> detailed logs are generated when the lock wait time exceeds
> deadlock_timeout.
> If set to "fail", logs are generated whenever a lock wait fails. If
> both are
> specified, logs would be triggered when the wait time exceeds
> deadlock_timeout or
> when a lock wait fails.
Thanks for the idea.
Changed log_lock_waits to an enum type and added fail and all.
"off" : No log message(default).
"on" : If over deadlock_timeout(the current behavior).
"fail" : If lock failed.
"all" : All pettern.
I struggled with the name "on," but decided to leave it by
compatibility.
Attachment | Content-Type | Size |
---|---|---|
v4-0001_add_loginfo_nowait.patch | text/x-diff | 12.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-10-18 10:11:00 | unicode test programs don't build with meson |
Previous Message | Amit Kapila | 2024-10-18 10:04:12 | Re: Enhance create subscription reference manual |