Re: Set log_lock_waits=on by default

On Fri, 2024-07-19 at 11:54 +0200, Laurenz Albe wrote: > On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote: > > 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 a

Re: Set log_lock_waits=on by default

Re: Jakub Wartak > 1. dev/testing DBs: where frankly speaking nobody cares about such DBs > until they stop/crash; this also includes DBs from new users on dev > laptops too > 2. production systems: where it matters to have log_lock_waits=on (and > people may start getting nervous if they don't hav

Re: Set log_lock_waits=on by default

On Fri, Jul 19, 2024 at 5:13 PM Robert Haas wrote: > > On Fri, Jul 19, 2024 at 10:22 AM Christoph Berg wrote: [..] > > Let's fix the default. People who have a problem can still disable it, > > but then everyone else gets the useful messages in the first iteration. > > Reasonable. > I have feeli

Re: Set log_lock_waits=on by default

On Fri, Jul 19, 2024 at 10:22 AM Christoph Berg wrote: > I'd argue this is exactly what I mean by "this system has a problem". > Telling the user about that makes sense. That's a fair position. > > cautious about this than most people on this thread: log_checkpoints > > won't generate more than

Re: Set log_lock_waits=on by default

Late to the party, but +1 from me on this default change also On Fri, 19 Jul 2024 at 11:54, Laurenz Albe wrote: > On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote: > > this patch is still on the table, though for v18 now. > > > > Nathan mentioned up-thread that he was hesitant to commit th

Re: Set log_lock_waits=on by default

> > Are there any others who have an opinion on this? Big +1 to having it on by default. It's already one of the first things I turn on by default on any system I come across. The log spam is minimal, compared to all the other stuff that ends up in there. And unlike most of that stuff, this is ou

Re: Set log_lock_waits=on by default

Re: Robert Haas > I've definitely seen systems where this setting would have generated > regular output, because I see a lot of systems that are chronically > overloaded. I'd argue this is exactly what I mean by "this system has a problem". Telling the user about that makes sense. > cautious abou

Re: Set log_lock_waits=on by default

On Fri, Jul 19, 2024 at 9:24 AM Christoph Berg wrote: > I have not seen any server yet where normal, legitimate operation > would routinely trigger the message. (If it did, people should likely > have used SKIP LOCKED or NOWAIT instead.) It would only increase the > log volume on systems that have

Re: Set log_lock_waits=on by default

Re: Laurenz Albe > The major criticism is Tom's that it might unduly increase the log volume. > > I'm not trying to rush things, but I see little point in kicking a trivial > patch like this through many commitfests. If no committer wants to step > up and commit this, it should be rejected. That

Re: Set log_lock_waits=on by default

On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote: > 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 i

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 h

Re: Set log_lock_waits=on by default

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > >> On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: > >>> 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 chat

Re: Set log_lock_waits=on by default

Stephen Frost writes: >> On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: >>> 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. >> Unsurprisingly, I want

Re: Set log_lock_waits=on by default

Greetings, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: > > Nathan Bossart writes: > > > It looks like there are two ideas: > > > [...] > > > * Set log_lock_waits on by default. The folks on this thread seem to > > > support this idea, b

Re: Set log_lock_waits=on by default

On Tue, 2024-02-06 at 12:29 -0500, Tom Lane wrote: > Nathan Bossart writes: > > It looks like there are two ideas: > > [...] > > * 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 defa

Re: Set log_lock_waits=on by default

Nathan Bossart 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. T

Re: Set log_lock_waits=on by default

I saw this was marked ready-for-committer, so I took a look at the thread. 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. IMHO this is arguably a prerequisite

Re: Set log_lock_waits=on by default

Hi, On Thu, Jan 11, 2024 at 03:24:55PM +0100, Michael Banck wrote: > On Thu, Dec 21, 2023 at 02:29:05PM +0100, Laurenz Albe wrote: > > Here is a patch to implement this. > > Being stuck behind a lock for more than a second is almost > > always a problem, so it is reasonable to turn this on by defa

Re: Set log_lock_waits=on by default

Hi, On Thu, Dec 21, 2023 at 02:29:05PM +0100, Laurenz Albe wrote: > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn this on by default. I also think that this should be set to on. I had a look at the

Re: Set log_lock_waits=on by default

On 12/21/23 6:58 AM, Nikolay Samokhvalov wrote: > On Thu, Dec 21, 2023 at 05:29 Laurenz Albe > wrote: > > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn th

Re: Set log_lock_waits=on by default

On 2023-12-22 20:00, Laurenz Albe wrote: My point is that in the vast majority of cases, long lock waits indicate a problem that you would like to know about, so the parameter should default to "on". +1. I always set log_lock_waits=on, so I agree with this. Just a random idea but what if we

Re: Set log_lock_waits=on by default

On Thu, 2023-12-21 at 09:14 -0500, Robert Haas wrote: > > I think it depends somewhat on the lock type, and also on your > threshold for what constitutes a problem. For example, you can wait > for 1 second for a relation extension lock pretty easily, I think, > just because the I/O system is busy.

Re: Set log_lock_waits=on by default

Re: Robert Haas > On Thu, Dec 21, 2023 at 8:29 AM Laurenz Albe wrote: > > Here is a patch to implement this. > > Being stuck behind a lock for more than a second is almost > > always a problem, so it is reasonable to turn this on by default. > > I think it depends somewhat on the lock type, and a

Re: Set log_lock_waits=on by default

Le 21/12/2023 à 14:29, Laurenz Albe a écrit : Here is a patch to implement this. Being stuck behind a lock for more than a second is almost always a problem, so it is reasonable to turn this on by default. I think it's a really good idea. At Dalibo, we advise our customers to switch it on.

Re: Set log_lock_waits=on by default

On Thu, Dec 21, 2023 at 05:29 Laurenz Albe wrote: > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn this on by default. I think it's a very good idea. On all heavily loaded systems I have observed so

Re: Set log_lock_waits=on by default

On Thu, Dec 21, 2023 at 8:29 AM Laurenz Albe wrote: > Here is a patch to implement this. > Being stuck behind a lock for more than a second is almost > always a problem, so it is reasonable to turn this on by default. I think it depends somewhat on the lock type, and also on your threshold for wh