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 system is mounted
     using the <literal>hard</literal> option.  With the
     <literal>hard</literal> option, processes can <quote>hang</quote>
     indefinitely if there are network problems, so this configuration will
     require a careful monitoring setup.  The <literal>soft</literal> option
     will interrupt system calls in case of network problems, but
     <productname>PostgreSQL</productname> will not repeat system calls
     interrupted in this way, so any such interruption will result in an I/O
     error being reported.
    </para>

    <para>
     It is not necessary to use the <literal>sync</literal> mount option.  The
     behavior of the <literal>async</literal> option is sufficient, since
     <productname>PostgreSQL</productname> issues <literal>fsync</literal>
     calls at appropriate times to flush the write caches.  (This is analogous
     to how it works on a local file system.)  However, it is strongly
     recommended to use the <literal>sync</literal> export option on the NFS
     <emphasis>server</emphasis> on systems where it exists (mainly Linux).
     Otherwise, an <literal>fsync</literal> or equivalent on the NFS client is
     not actually guaranteed to reach permanent storage on the server, which
     could cause corruption similar to running with the parameter <xref
     linkend="guc-fsync"/> off.  The defaults of these mount and export
     options differ between vendors and versions, so it is recommended to
     check and perhaps specify them explicitly in any case to avoid any
     ambiguity.
    </para>

    <para>
     In some cases, an external storage product can be accessed either via NFS
     or a lower-level protocol such as iSCSI.  In the latter case, the storage
     appears as a block device and any available file system can be created on
     it.  That approach might relieve the DBA from having to deal with some of
     the idiosyncrasies of NFS, but of course the complexity of managing
     remote storage then happens at other levels.
    </para>
   </sect3>
  </sect2>

 </sect1>

 <sect1 id="server-start">
  <title>Starting the Database Server</title>

  <para>
   Before anyone can access the database, you must start the database
   server. The database server program is called
   <command>postgres</command>.<indexterm><primary>postgres</primary></indexterm>
  </para>

  <para>
   If you are using a pre-packaged version
   of <productname>PostgreSQL</productname>, it almost certainly includes
   provisions for running the server as a background task according to the
   conventions of your operating system.  Using the package's
   infrastructure to start the server will be much less work than figuring
   out how to do this yourself.  Consult the package-level documentation
   for details.
  </para>

  <para>
   The bare-bones way to start the server manually is just to invoke
   <command>postgres</command> directly, specifying the location of the
   data directory with the <option>-D</option> option,