Re: Set log_lock_waits=on by default
Shinya Kato <shinya11.kato@oss.nttdata.com>
From: Shinya Kato <Shinya11.Kato@oss.nttdata.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-12-28T11:28:50Z
Lists: pgsql-hackers
On 2023-12-22 20:00, Laurenz Albe wrote: > My point is that in the vast majority of cases, long lock waits > indicate a problem that you would like to know about, so the parameter > should default to "on". +1. I always set log_lock_waits=on, so I agree with this. >> Just a random idea but what if we separated log_lock_waits from >> deadlock_timeout? Say, it becomes time-valued rather than >> Boolean-valued, but it has to be >= deadlock_timeout? Because I'd >> probably be more interested in hearing about a lock wait that was more >> than say 10 seconds, but I don't necessarily want to wait 10 seconds >> for the deadlock detector to trigger. > > That is an appealing thought, but as far as I know, "log_lock_waits" > is implemented by the deadlock detector, which is why it is tied to > "deadlock_timeout". So if we want that, we'd need a separate "live > lock detector". I don't know if we want to go there. Personally, I thought it was a good idea to separate log_lock_waits and deadlock_timeout, but I have not checked how that is implemented. -- Regards, Shinya Kato NTT DATA GROUP CORPORATION
Commits
-
Default to log_lock_waits=on
- 2aac62be8cbb 19 (unreleased) landed
-
Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited