it is taken as microseconds.
        The default <varname>commit_delay</varname> is zero (no delay).
        Only superusers and users with the appropriate <literal>SET</literal>
        privilege can change this setting.
       </para>
       <para>
        In <productname>PostgreSQL</productname> releases prior to 9.3,
        <varname>commit_delay</varname> behaved differently and was much
        less effective: it affected only commits, rather than all WAL flushes,
        and waited for the entire configured delay even if the WAL flush
        was completed sooner.  Beginning in <productname>PostgreSQL</productname> 9.3,
        the first process that becomes ready to flush waits for the configured
        interval, while subsequent processes wait only until the leader
        completes the flush operation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-siblings" xreflabel="commit_siblings">
      <term><varname>commit_siblings</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>commit_siblings</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Minimum number of concurrent open transactions to require
        before performing the <varname>commit_delay</varname> delay. A larger
        value makes it more probable that at least one other
        transaction will become ready to commit during the delay
        interval. The default is five transactions.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 id="runtime-config-wal-checkpoints">
     <title>Checkpoints</title>

    <variablelist>
     <varlistentry id="guc-checkpoint-timeout" xreflabel="checkpoint_timeout">
      <term><varname>checkpoint_timeout</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>checkpoint_timeout</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Maximum time between automatic WAL checkpoints.
        If this value is specified without units, it is taken as seconds.
        The valid range is between 30 seconds and one day.
        The default is five minutes (<literal>5min</literal>).
        Increasing this parameter can increase the amount of time needed
        for crash recovery.
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-checkpoint-completion-target" xreflabel="checkpoint_completion_target">
      <term><varname>checkpoint_completion_target</varname> (<type>floating point</type>)
      <indexterm>
       <primary><varname>checkpoint_completion_target</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the target of checkpoint completion, as a fraction of
        total time between checkpoints. The default is 0.9, which spreads the
        checkpoint across almost all of the available interval, providing fairly
        consistent I/O load while also leaving some time for checkpoint
        completion overhead.  Reducing this parameter is not recommended because
        it causes the checkpoint to complete faster.  This results in a higher
        rate of I/O during the checkpoint followed by a period of less I/O between
        the checkpoint completion and the next scheduled checkpoint.  This
        parameter can only be set in the <filename>postgresql.conf</filename> file
        or on the server command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-checkpoint-flush-after" xreflabel="checkpoint_flush_after">
      <term><varname>checkpoint_flush_after</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>checkpoint_flush_after</varname> configuration parameter</primary>