> > > 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
