<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.55 2007/11/0419:43:33 momjian Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.56 2007/11/0421:40:02 momjian Exp $ -->

<chapter id="managing-databases">

<title>Managing Databases</title>

the old tablespace locations.)

</para>

<sect2 id="manage-ag-tablespaces-nfs">

<title>Network File Systems</title>

<indexterm zone="manage-ag-tablespaces-nfs">

<primary>Network File Systems</primary>

</indexterm>

<indexterm><primary><acronym>NFS</></><see>Network File Systems</></>

<indexterm><primary>Network Attached Storage (<acronym>NAS</>)</><see>Network File Systems</></>

<para>

Many installations create tablespace on network file systems.

Sometimes this is done directly via <acronym>NFS</>, or by using a

Network Attached Storage (<acronym>NAS</>) device that uses

<acronym>NFS</> internally. <productname>PostgreSQL</> does nothing

special for <acronym>NFS</> file systems, meaning it assumes

<acronym>NFS</> behaves exactly like locally-connected drives. If

client and server <acronym>NFS</> implementations have non-standard

semantics, this can cause reliability problems (see <ulink

url="http://www.time-travellers.org/shane/papers/NFS_considered_harmful.html"></ulink>).

Specifically, delayed (asynchonous) writes to the <acronym>NFS</>

server can cause reliability problems; if possible, mount

<acronym>NFS</> file systems synchonously to avoid this.

</para>

</sect2>

</sect1>

</chapter>