system permissions to restrict connections. See <xref
   linkend="client-authentication"/> for more information.)
  </para>

  <para>
   <command>initdb</command> also initializes the default
   locale<indexterm><primary>locale</primary></indexterm> for the database cluster.
   Normally, it will just take the locale settings in the environment
   and apply them to the initialized database.  It is possible to
   specify a different locale for the database; more information about
   that can be found in <xref linkend="locale"/>.  The default sort order used
   within the particular database cluster is set by
   <command>initdb</command>, and while you can create new databases using
   different sort order, the order used in the template databases that initdb
   creates cannot be changed without dropping and recreating them.
   There is also a performance impact for using locales
   other than <literal>C</literal> or <literal>POSIX</literal>. Therefore, it is
   important to make this choice correctly the first time.
  </para>

  <para>
   <command>initdb</command> also sets the default character set encoding
   for the database cluster.  Normally this should be chosen to match the
   locale setting.  For details see <xref linkend="multibyte"/>.
  </para>

  <para>
   Non-<literal>C</literal> and non-<literal>POSIX</literal> locales rely on the
   operating system's collation library for character set ordering.
   This controls the ordering of keys stored in indexes.  For this reason,
   a cluster cannot switch to an incompatible collation library version,
   either through snapshot restore, binary streaming replication, a
   different operating system, or an operating system upgrade.
  </para>

  <sect2 id="creating-cluster-mount-points">
   <title>Use of Secondary File Systems</title>

   <indexterm zone="creating-cluster-mount-points">
    <primary>file system mount points</primary>
   </indexterm>

   <para>
    Many installations create their database clusters on file systems
    (volumes) other than the machine's <quote>root</quote> volume.  If you
    choose to do this, it is not advisable to try to use the secondary
    volume's topmost directory (mount point) as the data directory.
    Best practice is to create a directory within the mount-point
    directory that is owned by the <productname>PostgreSQL</productname>
    user, and then create the data directory within that.  This avoids
    permissions problems, particularly for operations such
    as <application>pg_upgrade</application>, and it also ensures clean failures if
    the secondary volume is taken offline.
   </para>

  </sect2>

  <sect2 id="creating-cluster-filesystem">
   <title>File Systems</title>

   <para>
    Generally, any file system with POSIX semantics can be used for
    PostgreSQL.  Users prefer different file systems for a variety of reasons,
    including vendor support, performance, and familiarity.  Experience
    suggests that, all other things being equal, one should not expect major
    performance or behavior changes merely from switching file systems or
    making minor file system configuration changes.
   </para>

   <sect3 id="creating-cluster-nfs">
    <title>NFS</title>

    <indexterm zone="creating-cluster-nfs">
     <primary>NFS</primary>
    </indexterm>

    <para>
     It is possible to use an <acronym>NFS</acronym> file system for storing
     the <productname>PostgreSQL</productname> data directory.
     <productname>PostgreSQL</productname> does nothing special for
     <acronym>NFS</acronym> file systems, meaning it assumes
     <acronym>NFS</acronym> behaves exactly like locally-connected drives.
     <productname>PostgreSQL</productname> does not use any functionality that
     is known to have nonstandard behavior on <acronym>NFS</acronym>, such as
     file locking.
    </para>

    <para>
     The only firm requirement for using <acronym>NFS</acronym> with
     <productname>PostgreSQL</productname> is that the file