Re: Set log_lock_waits=on by default

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 <nathandbossart(at)gmail(dot)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