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/
Attachment:
signature.asc
Description: This is a digitally signed message part
