Antes de continuar, deber�a usted conocer la arquitectura b�sica del sistema Postgres. El conocimiento de como interact�an las partes de Postgres deber�a aclararse algo durante el siguiente cap�tulo. En la jerga de las bases de datos, Postgres utiliza un simple modelo cliente/servidor de "proceso por usuario". Una sesi�n de Postgres consiste en los siguientes procesos Unix (programas) cooperando:
Un proceso demonio supervisor (postmaster),
la aplicaci�n de interface del usuario (frontend en ingl�s) (por ejemplo, el programa psql), y
los uno o m�s procesos servidores de acceso a la base de datos (backend en ingl�s) (el proceso postgres mismo).
Un �nico postmaster maneja una colecci�n dada de bases de datos en �nico host. Tal colecci�n se denomina una instalaci�n o un site. Las aplicaciones de frontend que quieren acceder a una base de datos dada en una instalaci�n realizan llamadas a la librer�a. La librer�a env�a el requerimiento del usuario a trav�s de la red al postmaster (C�mo se establece una conexi�n(a)), quien en su turno arranca un nuevo proceso servidor de backend (C�mo se establece una conexi�n(b))
y se conecta el proceso cliente al nuevo servidor (C�mo se establece una conexi�n(c)). > A partir de aqu�, el proceso cliente y el servidor se comunican entre ellos sin intervenci�n del postmaster. En consecuencia, el proceso postmaster est� siempre corriendo, esperando llamadas, mientras que los procesos cliente y servidor vienen y van. La librer�a libpq permite a un �nico proceso cliente tener m�ltiples conexiones con procesos servidores. Sin embargo, la aplicaci�n cliente sigue siendo un proceso mono-hebra. Las conexiones con multihebrado cliente/servidor no est�n actualmente soportadas en libpq. Una implicaci�n de esta arquitectura es que el postmaster y los servidores siempre corren en la misma m�quina (el servidor de base de datos), mientras que el cliente puede correr en cualquier sitio. Debe usted tener esto en cuenta, ya que los ficheros que pueden estar accesibles en una m�quina cliente, pueden no estarlo (o estarlo s�lo con un nombre de fichero diferente) en la m�quina servidor. Deber�a tener tambi�n en cuenta que postmaster y los servidores postgres corren bajo el user-id del "superusuario" de Postgres. N�tese que el superusuario de Postgres no tiene porqu� ser un usuario especial (es decir, un usuario llamado "postgres"), aunque en muchos sistemas est� instalado as�. M�s a�n, el superusuario de Postgres definitivamente �no debe de ser el superusuario de Unix, "root"! En cualquier caso, todos los ficheros relacionados con una base de datos deben encontrarse bajo este superusuario de Postgres.