Conceptos de Arquitectura de Postgres

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.