exception is that if the command was terminated by
    a signal (other than <systemitem>SIGTERM</systemitem>, which is used as
    part of a database server shutdown) or an error by the shell (such as
    command not found), then recovery will abort and the server will not start
    up.
   </para>

   <para>
    Not all of the requested files will be WAL segment
    files; you should also expect requests for files with a suffix of
    <literal>.history</literal>. Also be aware that
    the base name of the <literal>%p</literal> path will be different from
    <literal>%f</literal>; do not expect them to be interchangeable.
   </para>

   <para>
    WAL segments that cannot be found in the archive will be sought in
    <filename>pg_wal/</filename>; this allows use of recent un-archived segments.
    However, segments that are available from the archive will be used in
    preference to files in <filename>pg_wal/</filename>.
   </para>

   <para>
    Normally, recovery will proceed through all available WAL segments,
    thereby restoring the database to the current point in time (or as
    close as possible given the available WAL segments).  Therefore, a normal
    recovery will end with a <quote>file not found</quote> message, the exact text
    of the error message depending upon your choice of
    <varname>restore_command</varname>.  You may also see an error message
    at the start of recovery for a file named something like
    <filename>00000001.history</filename>.  This is also normal and does not
    indicate a problem in simple recovery situations; see
    <xref linkend="backup-timelines"/> for discussion.
   </para>

   <para>
    If you want to recover to some previous point in time (say, right before
    the junior DBA dropped your main transaction table), just specify the
    required <link linkend="runtime-config-wal-recovery-target">stopping point</link>.  You can specify
    the stop point, known as the <quote>recovery target</quote>, either by
    date/time, named restore point or by completion of a specific transaction
    ID.  As of this writing only the date/time and named restore point options
    are very usable, since there are no tools to help you identify with any
    accuracy which transaction ID to use.
   </para>

   <note>
     <para>
      The stop point must be after the ending time of the base backup, i.e.,
      the end time of <function>pg_backup_stop</function>.  You cannot use a base backup
      to recover to a time when that backup was in progress.  (To
      recover to such a time, you must go back to your previous base backup
      and roll forward from there.)
     </para>
   </note>

   <para>
    If recovery finds corrupted WAL data, recovery will
    halt at that point and the server will not start. In such a case the
    recovery process could be re-run from the beginning, specifying a
    <quote>recovery target</quote> before the point of corruption so that recovery
    can complete normally.
    If recovery fails for an external reason, such as a system crash or
    if the WAL archive has become inaccessible, then the recovery can simply
    be restarted and it will restart almost from where it failed.
    Recovery restart works much like checkpointing in normal operation:
    the server periodically forces all its state to disk, and then updates
    the <filename>pg_control</filename> file to indicate that the already-processed
    WAL data need not be scanned again.
   </para>

  </sect2>

  <sect2 id="backup-timelines">
   <title>Timelines</title>

  <indexterm zone="backup">
   <primary>timelines</primary>
  </indexterm>

   <para>
    The ability to restore the database to a previous point in time creates
    some complexities that are akin to science-fiction stories about time
    travel and parallel universes.  For example, in the original history of the database,
    suppose you dropped a critical table at 5:15PM on Tuesday evening, but
    didn't realize your mistake until