Hello
Yesterday we had a weird problem with the pg_xlog partition in one of
our servers:
- The amount of WAL files was much higher than (2*checkpoint_segments)+1
(over 360 WAL files)
- The WAL files were not created/recycle time-ordered. Here is an
example:
.....................
16777216 Apr 12 17:49 000000010000000D0000001C
16777216 Apr 12 17:49 000000010000000D0000001D
16777216 Apr 12 17:49 000000010000000D0000001E
16777216 Apr 12 17:52 000000010000000D0000001F
16777216 Apr 12 17:50 000000010000000D00000020
16777216 Apr 12 17:51 000000010000000D00000021
16777216 Apr 12 17:49 000000010000000D00000022
16777216 Apr 12 17:49 000000010000000D00000023
16777216 Apr 12 17:49 000000010000000D00000024
16777216 Apr 12 17:51 000000010000000D00000025
.....................
This is the first time I see this behavior with the result of a full
pg_xlog partition.
This happened when testing an upgrade procedure and moving on the fly
with "pg_dumpall | psql" around 30 databases (ca.140GB) from a 8.3
server to a 9.0 one.
Is this normal? If it is, how can we find out the max.number of WAL
files a 9.0 system can generate in the worst case scenario?
Some relevant information about this system:
------------------------------------------------
PostgreSQL 9.0.3 - ext4 - RHEL5.6 - 2.6.18-238.5.1.el5 - x86_64
checkpoint_segments: 128
wal_buffers: 512kB
wal_level: archive
wal_sync_method: fdatasync
shared_buffers: 10GB
------------------------------------------------
regards,
--
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
