Nathan Bossart <nathandbossart@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