row-level change data
        normally stored in WAL will not be enough to completely restore
        such a page during post-crash recovery.  Storing the full page image
        guarantees that the page can be correctly restored, but at the price
        of increasing the amount of data that must be written to WAL.
        (Because WAL replay always starts from a checkpoint, it is sufficient
        to do this during the first change of each page after a checkpoint.
        Therefore, one way to reduce the cost of full-page writes is to
        increase the checkpoint interval parameters.)
       </para>

       <para>
        Turning this parameter off speeds normal operation, but
        might lead to either unrecoverable data corruption, or silent
        data corruption, after a system failure. The risks are similar to turning off
        <varname>fsync</varname>, though smaller, and it should be turned off
        only based on the same circumstances recommended for that parameter.
       </para>

       <para>
        Turning off this parameter does not affect use of
        WAL archiving for point-in-time recovery (PITR)
        (see <xref linkend="continuous-archiving"/>).
       </para>

       <para>
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
        The default is <literal>on</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-log-hints" xreflabel="wal_log_hints">
      <term><varname>wal_log_hints</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>wal_log_hints</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When this parameter is <literal>on</literal>, the <productname>PostgreSQL</productname>
        server writes the entire content of each disk page to WAL during the
        first modification of that page after a checkpoint, even for
        non-critical modifications of so-called hint bits.
       </para>

       <para>
        If data checksums are enabled, hint bit updates are always WAL-logged
        and this setting is ignored. You can use this setting to test how much
        extra WAL-logging would occur if your database had data checksums
        enabled.
       </para>

       <para>
        This parameter can only be set at server start. The default value is <literal>off</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-compression" xreflabel="wal_compression">
      <term><varname>wal_compression</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>wal_compression</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        This parameter enables compression of WAL using the specified
        compression method.
        When enabled, the <productname>PostgreSQL</productname>
        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.