<!--
doc/src/sgml/ref/pg_resetwal.sgml
PostgreSQL documentation
-->

<refentry id="app-pgresetwal">
 <indexterm zone="app-pgresetwal">
  <primary>pg_resetwal</primary>
 </indexterm>

 <refmeta>
  <refentrytitle><application>pg_resetwal</application></refentrytitle>
  <manvolnum>1</manvolnum>
  <refmiscinfo>Application</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>pg_resetwal</refname>
  <refpurpose>reset the write-ahead log and other control information of a <productname>PostgreSQL</productname> database cluster</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
  <cmdsynopsis>
   <command>pg_resetwal</command>
   <group choice="opt">
    <arg choice="plain"><option>-f</option></arg>
    <arg choice="plain"><option>--force</option></arg>
   </group>
   <group choice="opt">
    <arg choice="plain"><option>-n</option></arg>
    <arg choice="plain"><option>--dry-run</option></arg>
   </group>
   <arg rep="repeat"><replaceable>option</replaceable></arg>
   <group choice="plain">
    <group choice="opt">
     <arg choice="plain"><option>-D</option></arg>
     <arg choice="plain"><option>--pgdata</option></arg>
    </group>
    <replaceable class="parameter">datadir</replaceable>
   </group>
  </cmdsynopsis>
 </refsynopsisdiv>

 <refsect1 id="r1-app-pgresetwal-1">
  <title>Description</title>
  <para>
   <command>pg_resetwal</command> clears the write-ahead log (WAL) and
   optionally resets some other control information stored in the
   <filename>pg_control</filename> file.  This function is sometimes needed
   if these files have become corrupted.  It should be used only as a
   last resort, when the server will not start due to such corruption.
  </para>

  <para>
   Some options, such as <option>--wal-segsize</option> (see below), can also
   be used to modify certain global settings of a database cluster without the
   need to rerun <command>initdb</command>.  This can be done safely on an
   otherwise sound database cluster, if none of the dangerous modes mentioned
   below are used.
  </para>

  <para>
   If <command>pg_resetwal</command> is used on a data directory where the
   server has been cleanly shut down and the control file is sound, then it
   will have no effect on the contents of the database system, except that no
   longer used WAL files are cleared away.  Any other use is potentially
   dangerous and must be done with great care.  <command>pg_resetwal</command>
   will require the <option>-f</option> (force) option to be specified before
   working on a data directory in an unclean shutdown state or with a
   corrupted control file.
  </para>

  <para>
   After running this command on a data directory with corrupted WAL or a
   corrupted control file, it should be possible to start the server,
   but bear in mind that the database might contain inconsistent data due to
   partially-committed transactions.  You should immediately dump your data,
   run <command>initdb</command>, and restore.  After restore, check for
   inconsistencies and repair as needed.
  </para>

  <para>
   If <command>pg_resetwal</command> complains that it cannot determine
   valid data for <filename>pg_control</filename>, you can force it to proceed anyway
   by specifying the <option>-f</option> (force) option.  In this case plausible
   values will be substituted for the missing data.  Most of the fields can be
   expected to match, but manual assistance might be needed for the next OID,
   next transaction ID and epoch, next multitransaction ID and offset, and
   WAL starting location fields. These fields can be set using the options
   discussed below. If you are not able to determine correct values for all
   these fields, <option>-f</option> can still be used, but
   the recovered database must be treated with even more suspicion than
   usual: an immediate dump and restore is imperative.  <emphasis>Do not</emphasis>
   execute any data-modifying operations in the database before you dump,
   as any such action is likely to make