> > > 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. > > > > Wouldn't it be more useful to increase the WAL segment size on such > > installations > > that switch WAL files so frequently that it is a problem for the log ? > > > > This currently needs a recompile. I wondered for some time now whether > > 16 Mb isn't > > too low for current hw. 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. The > performance advantages of that have been mostly removed in 8.3, you > should note.
Oh sorry, this was definitely not meant for 8.3. And here I didn't mean the performance of the db issue, but an issue for archiving the WAL files. I think most archiving systems are not too happy with extremely frequent backup calls. Also the overall handling of too many WAL files is imho not handy. Andreas ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
