server compresses full page images written to WAL when
<xref linkend="guc-full-page-writes"/> is on or during a base backup.
A compressed page image will be decompressed during WAL replay.
The supported methods are <literal>pglz</literal>,
<literal>lz4</literal> (if <productname>PostgreSQL</productname>
was compiled with <option>--with-lz4</option>) and
<literal>zstd</literal> (if <productname>PostgreSQL</productname>
was compiled with <option>--with-zstd</option>).
The default value is <literal>off</literal>.
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
</para>
<para>
Enabling compression can reduce the WAL volume without
increasing the risk of unrecoverable data corruption,
but at the cost of some extra CPU spent on the compression during
WAL logging and on the decompression during WAL replay.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-wal-init-zero" xreflabel="wal_init_zero">
<term><varname>wal_init_zero</varname> (<type>boolean</type>)
<indexterm>
<primary><varname>wal_init_zero</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
If set to <literal>on</literal> (the default), this option causes new
WAL files to be filled with zeroes. On some file systems, this ensures
that space is allocated before we need to write WAL records. However,
<firstterm>Copy-On-Write</firstterm> (COW) file systems may not benefit
from this technique, so the option is given to skip the unnecessary
work. If set to <literal>off</literal>, only the final byte is written
when the file is created so that it has the expected size.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-wal-recycle" xreflabel="wal_recycle">
<term><varname>wal_recycle</varname> (<type>boolean</type>)
<indexterm>
<primary><varname>wal_recycle</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
If set to <literal>on</literal> (the default), this option causes WAL
files to be recycled by renaming them, avoiding the need to create new
ones. On COW file systems, it may be faster to create new ones, so the
option is given to disable this behavior.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-wal-buffers" xreflabel="wal_buffers">
<term><varname>wal_buffers</varname> (<type>integer</type>)
<indexterm>
<primary><varname>wal_buffers</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
The amount of shared memory used for WAL data that has not yet been
written to disk. The default setting of -1 selects a size equal to
1/32nd (about 3%) of <xref linkend="guc-shared-buffers"/>, but not less
than <literal>64kB</literal> nor more than the size of one WAL
segment, typically <literal>16MB</literal>. This value can be set
manually if the automatic choice is too large or too small,
but any positive value less than <literal>32kB</literal> will be
treated as <literal>32kB</literal>.
If this value is specified without units, it is taken as WAL blocks,
that is <symbol>XLOG_BLCKSZ</symbol> bytes, typically 8kB.
This parameter can only be set at server start.
</para>
<para>
The contents of the WAL buffers are written out to disk at every
transaction commit, so extremely large values are unlikely to
provide a significant benefit. However, setting this value to at
least a few megabytes can improve write performance on a busy
server where many clients are committing