order
      (according to C locale rules, i.e., numbers before letters, and
      uppercase letters before lowercase ones).
     </para>

     <para>
      Include files or directories can be used to logically separate portions
      of the database configuration, rather than having a single large
      <filename>postgresql.conf</filename> file.  Consider a company that has two
      database servers, each with a different amount of memory.  There are
      likely elements of the configuration both will share, for things such
      as logging.  But memory-related parameters on the server will vary
      between the two.  And there might be server specific customizations,
      too.  One way to manage this situation is to break the custom
      configuration changes for your site into three files.  You could add
      this to the end of your <filename>postgresql.conf</filename> file to include
      them:
<programlisting>
include 'shared.conf'
include 'memory.conf'
include 'server.conf'
</programlisting>
      All systems would have the same <filename>shared.conf</filename>.  Each
      server with a particular amount of memory could share the
      same <filename>memory.conf</filename>; you might have one for all servers
      with 8GB of RAM, another for those having 16GB.  And
      finally <filename>server.conf</filename> could have truly server-specific
      configuration information in it.
     </para>

     <para>
      Another possibility is to create a configuration file directory and
      put this information into files there. For example, a <filename>conf.d</filename>
      directory could be referenced at the end of <filename>postgresql.conf</filename>:
<programlisting>
include_dir 'conf.d'
</programlisting>
      Then you could name the files in the <filename>conf.d</filename> directory
      like this:
<programlisting>
00shared.conf
01memory.conf
02server.conf
</programlisting>
       This naming convention establishes a clear order in which these
       files will be loaded.  This is important because only the last
       setting encountered for a particular parameter while the server is
       reading configuration files will be used.  In this example,
       something set in <filename>conf.d/02server.conf</filename> would override a
       value set in <filename>conf.d/01memory.conf</filename>.
     </para>

     <para>
      You might instead use this approach to naming the files
      descriptively:
<programlisting>
00shared.conf
01memory-8GB.conf
02server-foo.conf
</programlisting>
      This sort of arrangement gives a unique name for each configuration file
      variation.  This can help eliminate ambiguity when several servers have
      their configurations all stored in one place, such as in a version
      control repository.  (Storing database configuration files under version
      control is another good practice to consider.)
     </para>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-file-locations">
    <title>File Locations</title>

     <para>
      In addition to the <filename>postgresql.conf</filename> file
      already mentioned, <productname>PostgreSQL</productname> uses
      two other manually-edited configuration files, which control
      client authentication (their use is discussed in <xref
      linkend="client-authentication"/>).  By default, all three
      configuration files are stored in the database cluster's data
      directory.  The parameters described in this section allow the
      configuration files to be placed elsewhere.  (Doing so can ease
      administration.  In particular it is often easier to ensure that
      the configuration files are properly backed-up when they are
      kept separate.)
     </para>

     <variablelist>
     <varlistentry id="guc-data-directory" xreflabel="data_directory">
      <term><varname>data_directory</varname> (<type>string</type>)
      <indexterm>
       <primary><varname>data_directory</varname> configuration parameter</primary>