Re: Set log_lock_waits=on by default - Mailing list pgsql-hackers

From Michael Banck
Subject Re: Set log_lock_waits=on by default
Date
Msg-id 6698edb4.5d0a0220.df6fa.5b59@mx.google.com
Whole thread Raw
In response to Re: Set log_lock_waits=on by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Set log_lock_waits=on by default
Re: Set log_lock_waits=on by default
List pgsql-hackers
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@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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Duplicate unique key values in inheritance tables
Next
From: Ashutosh Bapat
Date:
Subject: Re: Add mention of execution time memory for enable_partitionwise_* GUCs