Gavan Schneider <pg-gts@snkmail.com> writes:
> My surprise is that with the data on board, and nothing
> happening, those WAL files now appear to have a lot more real
> content, i.e., I am assuming this means the data and/or
> configuration are getting altered even when there are no
> connections. I know vacuum can change things but surely it
> should run out of things to do after a few passes.
In the base configuration, an idle Postgres installation won't generate
any fresh WAL; but this isn't true if you've got hot-standby replication
configured, because of the effect described here:
http://archives.postgresql.org/pgsql-hackers/2011-10/msg00207.php
The quick-and-dirty patch that was proposed in that thread was later
found to have problems of its own and reverted, so right at the moment
we're back to the behavior Fujii-san described. I'm not sure if anyone
is thinking about other ways to avoid it; a few bytes of WAL every ten
minutes is not the end of the world exactly, especially since hot
standby is typically used in installations that are far from idle.
However, you've got a bigger problem because it appears you're getting
a WAL file switch after each checkpoint, which does *not* happen in a
minimal replication configuration. I suspect you have archive_timeout
activated. You might want to reconsider those settings: the combination
of hot standby and archive timeout seems a bit redundant to me. If
you're relying on a hot standby then you don't really need to worry
about keeping the WAL archive fully up-to-date, and contrarily if you
aren't using a hot standby then you should back off the wal_level
setting to eliminate unnecessary WAL traffic.
regards, tom lane