Message-ID: <6698edb4.5d0a0220.df6fa.5b59@mx.google.com>
Sender: Michael Banck <mbanck@gmail.com>
Date: Thu, 18 Jul 2024 12:25:55 +0200
From: Michael Banck <mbanck@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Set log_lock_waits=on by default
References: <b8b8502915e50f44deb111bc0b43a99e2733e117.camel@cybertec.at>
 <659ffa38.170a0220.eea6a.28fc@mx.google.com>
 <65b146b9.170a0220.c645b.0891@mx.google.com>
 <20240206165343.GA3841415@nathanxps13>
 <524751.1707240550@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <524751.1707240550@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://www.postgresql.org/message-id/6698edb4.5d0a0220.df6fa.5b59%40mx.google.com>
Precedence: bulk

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