<term><option>--version</option></term>
    <listitem><para>Display version information, then exit.</para></listitem>
   </varlistentry>

   <varlistentry>
    <term><option>-?</option></term>
    <term><option>--help</option></term>
    <listitem><para>Show help, then exit.</para></listitem>
   </varlistentry>
  </variablelist>

  <para>
   The following options are only needed when
   <command>pg_resetwal</command> is unable to determine appropriate values
   by reading <filename>pg_control</filename>.  Safe values can be determined as
   described below.  For values that take numeric arguments, hexadecimal
   values can be specified by using the prefix <literal>0x</literal>.  Note
   that these instructions only apply with the standard block size of 8 kB.
  </para>

  <variablelist>
   <varlistentry>
    <term><option>-c <replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
    <term><option>--commit-timestamp-ids=<replaceable class="parameter">xid</replaceable>,<replaceable class="parameter">xid</replaceable></option></term>
    <listitem>
     <para>
      Manually set the oldest and newest transaction IDs for which the commit
      time can be retrieved.
     </para>

     <para>
      A safe value for the oldest transaction ID for which the commit time can
      be retrieved (first part) can be determined by looking
      for the numerically smallest file name in the directory
      <filename>pg_commit_ts</filename> under the data directory.  Conversely, a safe
      value for the newest transaction ID for which the commit time can be
      retrieved (second part) can be determined by looking for the numerically
      greatest file name in the same directory.  The file names are in
      hexadecimal.
     </para>
      <!-- XXX: Should there be a multiplier, similar to the other options? -->
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><option>-e <replaceable class="parameter">xid_epoch</replaceable></option></term>
    <term><option>--epoch=<replaceable class="parameter">xid_epoch</replaceable></option></term>
    <listitem>
     <para>
      Manually set the next transaction ID's epoch.
     </para>

     <para>
      The transaction ID epoch is not actually stored anywhere in the database
      except in the field that is set by <command>pg_resetwal</command>,
      so any value will work so far as the database itself is concerned.
      You might need to adjust this value to ensure that replication
      systems such as <application>Slony-I</application> and
      <application>Skytools</application> work correctly &mdash;
      if so, an appropriate value should be obtainable from the state of
      the downstream replicated database.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><option>-l <replaceable class="parameter">walfile</replaceable></option></term>
    <term><option>--next-wal-file=<replaceable class="parameter">walfile</replaceable></option></term>
    <listitem>
     <para>
      Manually set the WAL starting location by specifying the name of the
      next WAL segment file.
     </para>

     <para>
      The name of next WAL segment file should be
      larger than any WAL segment file name currently existing in
      the directory <filename>pg_wal</filename> under the data directory.
      These names are also in hexadecimal and have three parts.  The first
      part is the <quote>timeline ID</quote> and should usually be kept the same.
      For example, if <filename>00000001000000320000004A</filename> is the
      largest entry in <filename>pg_wal</filename>, use <literal>-l 00000001000000320000004B</literal> or higher.
     </para>

     <para>
      Note that when using nondefault WAL segment sizes, the numbers in the WAL
      file names are different from the LSNs that are reported by system
      functions and system views.  This option takes a WAL file name, not an
      LSN.
     </para>