<indexterm zone="routine-reindex">
   <primary>reindex</primary>
  </indexterm>

  <para>
   In some situations it is worthwhile to rebuild indexes periodically
   with the <xref linkend="sql-reindex"/> command or a series of individual
   rebuilding steps.

  </para>

  <para>
   B-tree index pages that have become completely empty are reclaimed for
   re-use.  However, there is still a possibility
   of inefficient use of space: if all but a few index keys on a page have
   been deleted, the page remains allocated.  Therefore, a usage
   pattern in which most, but not all, keys in each range are eventually
   deleted will see poor use of space.  For such usage patterns,
   periodic reindexing is recommended.
  </para>

  <para>
   The potential for bloat in non-B-tree indexes has not been well
   researched.  It is a good idea to periodically monitor the index's physical
   size when using any non-B-tree index type.
  </para>

  <para>
   Also, for B-tree indexes, a freshly-constructed index is slightly faster to
   access than one that has been updated many times because logically
   adjacent pages are usually also physically adjacent in a newly built index.
   (This consideration does not apply to non-B-tree indexes.)  It
   might be worthwhile to reindex periodically just to improve access speed.
  </para>

  <para>
   <xref linkend="sql-reindex"/> can be used safely and easily in all cases.
   This command requires an <literal>ACCESS EXCLUSIVE</literal> lock by
   default, hence it is often preferable to execute it with its
   <literal>CONCURRENTLY</literal> option, which requires only a
   <literal>SHARE UPDATE EXCLUSIVE</literal> lock.
  </para>
 </sect1>


 <sect1 id="logfile-maintenance">
  <title>Log File Maintenance</title>

  <indexterm zone="logfile-maintenance">
   <primary>server log</primary>
   <secondary>log file maintenance</secondary>
  </indexterm>

  <para>
   It is a good idea to save the database server's log output
   somewhere, rather than just discarding it via <filename>/dev/null</filename>.
   The log output is invaluable when diagnosing
   problems.
  </para>

  <note>
   <para>
    The server log can contain sensitive information and needs to be protected,
    no matter how or where it is stored, or the destination to which it is routed.
    For example, some DDL statements might contain plaintext passwords or other
    authentication details. Logged statements at the <literal>ERROR</literal>
    level might show the SQL source code for applications
    and might also contain some parts of data rows. Recording data, events and
    related information is the intended function of this facility, so this is
    not a leakage or a bug. Please ensure the server logs are visible only to
    appropriately authorized people.
   </para>
  </note>

  <para>
   Log output tends to be voluminous
   (especially at higher debug levels) so you won't want to save it
   indefinitely.  You need to <emphasis>rotate</emphasis> the log files so that
   new log files are started and old ones removed after a reasonable
   period of time.
  </para>

  <para>
   If you simply direct the <systemitem>stderr</systemitem> of
   <command>postgres</command> into a
   file, you will have log output, but
   the only way to truncate the log file is to stop and restart
   the server. This might be acceptable if you are using
   <productname>PostgreSQL</productname> in a development environment,
   but few production servers would find this behavior acceptable.
  </para>

  <para>
   A better approach is to send the server's
   <systemitem>stderr</systemitem> output to some type of log rotation program.
   There is a built-in log rotation facility, which you can use by
   setting the configuration parameter <varname>logging_collector</varname> to
   <literal>true</literal> in <filename>postgresql.conf</filename>.  The control
   parameters for this program are described in <xref
   linkend="runtime-config-logging-where"/>. You can