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 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. Well, it's still limited by 1 message per second (times max_connections). It won't suddenly fill up the server with 1000 messages per second. The log volume is the lesser of the problems. Not printing the message just because the system does have a problem isn't the right fix. > 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. 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. Christoph
