Hi, this patch is still on the table, though for v18 now.
Nathan mentioned up-thread that he was hesitant to commit this without further discussion. Laurenz, Stephen and I are +1 on this, but when it comes to committers having chimed in only Tom did so far and was -1. Are there any others who have an opinion on this? On Tue, Feb 06, 2024 at 12:29:10PM -0500, Tom Lane wrote: > Nathan Bossart <nathandboss...@gmail.com> writes: > > It looks like there are two ideas: > > > * Separate log_lock_waits from deadlock_timeout. It looks like this idea > > has a decent amount of support, but I didn't see any patch for it so far. > > I think the support comes from people who have not actually looked at > the code. The reason they are not separate is that the same timeout > service routine does both things. To pull them apart, you would have > to (1) detangle that code and (2) incur the overhead of two timeout > events queued for every lock wait. It's not clear to me that it's > worth it. In some sense, deadlock_timeout is exactly the length of > time after which you want to get concerned. > > > IMHO this is arguably a prerequisite for setting log_lock_waits on by > > default, as we could then easily set it higher by default to help address > > concerns about introducing too much noise in the logs. > > Well, that's the question --- would it be sane to enable > log_lock_waits by default if we don't separate them? I think it would be, I have not seen people change the value of deadlock_timeout so far, and I think 1s is a reasonable long time for a default lock wait to be reported. > > * Set log_lock_waits on by default. The folks on this thread seem to > > support this idea, but given the lively discussion for enabling > > log_checkpoints by default [0], I'm hesitant to commit something like > > this without further community discussion. > > I was, and remain, of the opinion that that was a bad idea that > we'll eventually revert, just like we previously got rid of most > inessential log chatter in the default configuration. I somewhat agree here in the sense that log_checkpoints is really only useful for heavily-used servers, but this is a digression and due to the fact that log_checkpoints emits log lines periodically while log_lock_waits only emits them for application conflicts (and arguably application bugs), I do not think those would be in the "issential log chatter" group similar to how all SQL errors are not in that group either. Michael
