Home Explore Blog CI



postgresql

51th chunk of `doc/src/sgml/config.sgml`
dc07307e16a6f94fb09a62bce797d7a28e72c1192874e48b0000000100000fa8
    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

Title: WAL Compression, Initialization, Recycling, and Buffers in PostgreSQL
Summary
This section describes further WAL configurations in PostgreSQL. It details `wal_compression`, which enables compression of WAL data (full page images) using pglz, lz4, or zstd, reducing WAL volume with a CPU cost. It then covers `wal_init_zero`, controlling whether new WAL files are filled with zeroes, and `wal_recycle`, which determines if WAL files are recycled by renaming them. Finally, it explains `wal_buffers`, configuring the shared memory for WAL data before it's written to disk, impacting write performance.