Simon Riggs <simon@2ndquadrant.com> writes: > Perhaps we should move the successful archived message to DEBUG1 now, > except for the first message after the archiver starts or when the > archive_command changes, plus one message every 255 segments? That would > reduce the log volume in the normal case without endangering our ability > to see what is happening. That would confuse people terribly, and it *would* endanger our ability to see what was happening, 254 times out of 255. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Simon Riggs <simon@2ndquadrant.com> writes: > On Wed, 2007-11-21 at 11:27 -0500, Tom Lane wrote: >> That would confuse people terribly, and it *would* endanger our ability >> to see what was happening, 254 times out of 255. > That's my feeling too, just wanted to check it still made sense for > y'all. Just to clarify: I don't object to lowering "successfully archived" messages to DEBUG1, if the field consensus is that it's too chatty. What I didn't like was the idea of logging some events but not other identical events. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Just to clarify: I don't object to lowering "successfully archived" >> messages to DEBUG1, if the field consensus is that it's too chatty. >> What I didn't like was the idea of logging some events but not other >> identical events. > Agreed on the intermittent logging. I don't feel it's too chatty, > but on the other hand, I could always change the logging level on > the fly if I was investigating a problem, so it wouldn't be much of > an inconvenience to switch it if it bugs others. Also, you can always tweak your archive_command script to do some logging of its own, so it's always possible to make the thing more noisy if you need to. Less noisy, though, is hard without changing the server code. > In poking around the logs just now, I noticed one message I'd like > to squelch. Run against Milwaukee County's recent log files: > grep -c 'PRIMARY KEY will create implicit index' Set log_min_messages higher than NOTICE. Given the current usage of NOTICE --- basically they're *all* newbie-annoyance items --- I kinda wonder why WARNING isn't the default setting anyway. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

Simon Riggs <simon@2ndquadrant.com> writes: > On Wed, 2007-11-21 at 18:16 +0100, Zeugswetter Andreas ADI SD wrote: >> Maybe it is time for making WAL segment size >> changeable in the conf with a clean shutdown. > I think its too late in the release cycle to fully consider all the > implications of that. 16MB is hardcoded in lots of places. Starting with the WAL file names. You couldn't even find the last checkpoint record if this were changed between shutdown and restart; you'd very likely go looking under the wrong filename, and even if you hit on an existent filename you'd be looking at the wrong offset within it. I don't think that should even be a TODO item --- it seems far more likely to provide a foot-gun than useful capability. Whether 16MB is still a reasonable default segment size is worth questioning, though I don't think that increasing it is an open-and-shut proposition. Larger segments mean more overhead in configurations that force frequent segment switches, for instance. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Simon Riggs <simon@2ndquadrant.com> writes: > On Thu, 2007-11-22 at 10:34 +0100, Zeugswetter Andreas ADI SD wrote: >> On further reflection I think that initdb time is probably sufficient. >> Do you think that would be a reasonable TODO ? > I think you'd have to explain why this was needed. It was useful for > performance once, but not anymore. Yeah, some demonstration that choosing another size is actually useful would be a good idea before we go to the trouble of making it runtime configurable. It's already build-time configurable, and I'm not convinced that that's not sufficient. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate