On Fri, Jul 19, 2024 at 9:24 AM Christoph Berg <m...@debian.org> 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 a problem.
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 think waits of more than 1 second for tuple locks could be pretty routine on some servers -- or XID or VXID locks. So I'm more cautious about this than most people on this thread: log_checkpoints won't generate more than a few lines of output per checkpoint interval, and a checkpoint cycle will be on the order of minutes, so it's really never that much volume. On the other hand, in theory, this setting can generate arbitrarily many messages. That's why I originally proposed separating deadlock_timeout from log_lock_waits, because I think 1s might actually end up being kind of noisy for some people. On the other hand, I take Tom's point that separating those things would be hard to code and, probably more importantly, require a second timer. I'm not strongly opposed to just turning this on by default. It's not like we can't change our minds, and it's also not like individual customers can't change the default. I think Tom has entirely the wrong idea about what a typical log file on a production server looks like. In every case I've seen, it's full of application generated errors that will never be fixed, connection logging, statement logging, and other stuff that is there just in case but will normally be ignored. Finding the messages that indicate real database problems is typically quite difficult, even if they're all enabled. If they're disabled by default, well then the useless crap is the ONLY thing you find in the log file, and when the customer has a problem, the first thing you have to do is tell them to turn on all the GUCs that log the actually important stuff and wait until the problem recurs. I have yet to run into a customer who was thrilled about receiving that message. -- Robert Haas EDB: http://www.enterprisedb.com
