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

<!-- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.57 2007/11/08 15:21:03 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>

<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.384 2007/11/0421:50:28 momjian Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.385 2007/11/08 15:21:03 momjian Exp $ -->

<chapter Id="runtime">

<title>Operating System Environment</title>

locale setting. For details see <xref linkend="multibyte">.

</para>

<para>

If using non-local (network) file systems, see <xref

linkend="manage-ag-tablespaces-nfs">.

</para>

<sect2 id="creating-cluster-nfs">

<title>Network File Systems</title>

<indexterm zone="creating-cluster-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 database clusters 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

(<acronym>DAS</>, Direct Attached Storage). 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 (without caching) to avoid

this. (Storage Area Networks (<acronym>SAN</>) use a low-level

communication protocol rather than <acronym>NFS</>.)

</para>

</sect2>

</sect1>