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? > * 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. So I doubt you'll have much trouble guessing my opinion of this one. I think the default logging configuration should be chosen with the understanding that nobody ever looks at the logs of most installations, and we should be more worried about their disk space consumption than anything else. Admittedly, log_lock_waits is less bad than log_checkpoints, because no such events will occur in a well-tuned configuration ... but still, it's going to be useless chatter in the average installation. regards, tom lane