On Fri, Jul 22, 2016 at 6:02 PM, Chapman Flack <c...@anastigmatix.net> wrote: > At $work, we have a usually-low-activity PG database, so that almost > always the used fraction of each 16 MB WAL segment is far smaller > than 16 MB, and so it's a big win for archived-WAL storage space > if an archive-command can be written that compresses those files > effectively.
I'm kind of curious WHY you are using archiving and forcing regular segment switches rather than just using streaming replication. Pre-9.0, use of archive_timeout was routine, since there was no other way to ensure that the data ended up someplace other than your primary with reasonable regularity. But, AFAIK, streaming replication essentially obsoleted that use case. You can just dribble the individual bytes over the wire a few at a time to the standby or, with pg_receivexlog, to an archive location. If it takes 6 months to fill up a WAL segment, you don't care: you'll always have all the bytes that were generated more than a fraction of a second before the master melted into a heap of slag. I'm not saying you don't have a good reason for doing what you are doing, just that I cannot think of one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
