In thinking about how to communicate to users about reducing continuous
archiving storage requirements, I realized we don't mention pglesslog in
our official documentation.
The attached patch documents how to use pglesslog and gzip/gunzip to
reduce storage requirements. Comments?
Also, I assume pg_lesslog removes the padding we use to make all WAL
files 16MB, effectively doing the function of clearxlogtail too, right?
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.121
diff -c -c -r2.121 backup.sgml
*** doc/src/sgml/backup.sgml 9 Nov 2008 17:51:15 -0000 2.121
--- doc/src/sgml/backup.sgml 11 Jan 2009 01:41:12 -0000
***************
*** 1337,1342 ****
--- 1337,1359 ----
WAL files are part of the same <application>tar</> file.
Please remember to add error handling to your backup scripts.
</para>
+
+ <para>
+ If archive storage size is a concern, use <application>pg_compresslog</>,
+ <ulink url="http://pglesslog.projects.postgresql.org";></ulink>, to
+ remove unnecessary <xref linkend="guc-full-page-writes"> and trailing
+ space from the WAL files. You can then use
+ <application>gzip</application> to further compress the output of
+ <application>pg_compresslog</>:
+ <programlisting>
+ archive_command = 'pg_compresslog %p - | gzip > /var/lib/pgsql/archive/%f'
+ </programlisting>
+ You will then need to use <application>gunzip</> and
+ <application>pg_decompresslog</> during recovery:
+ <programlisting>
+ restore_command = 'gunzip < /mnt/server/archivedir/%f | pg_decompresslog - %p'
+ </programlisting>
+ </para>
</sect3>
<sect3 id="backup-scripts">
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
