Chapter 10.
Architecture

Before we begin, you should understand the basic
PostgreSQL system
architecture. Understanding how the parts of PostgreSQL interact will make the next
chapter somewhat clearer. In database jargon, PostgreSQL uses a simple "process
per-user" client/server model. A PostgreSQL session consists of the
following cooperating Unix processes (programs):

A supervisory daemon process (the postmaster),

the user's frontend application (e.g., the psql program), and

one or more backend database servers (the postgres process itself).

A single postmaster manages
a given collection of databases on a single host. Such a
collection of databases is called a cluster (of databases). A
frontend application that wishes to access a given database
within a cluster makes calls to an interface library (e.g.,
libpq) that is linked into the
application. The library sends user requests over the network
to the postmaster (Figure 10-1(a)), which in
turn starts a new backend server process (Figure 10-1(b))

Figure 10-1. How a connection is
established

and connects the frontend process to the new server
(Figure 10-1(c)).
From that point on, the frontend process and the backend server
communicate without intervention by the postmaster. Hence, the postmaster is always running, waiting for
connection requests, whereas frontend and backend processes
come and go. The libpq library allows
a single frontend to make multiple connections to backend
processes. However, each backend process is a single-threaded
process that can only execute one query at a time; so the
communication over any one frontend-to-backend connection is
single-threaded.

One implication of this architecture is that the
postmaster and the backend
always run on the same machine (the database server), while the
frontend application may run anywhere. You should keep this in
mind, because the files that can be accessed on a client
machine may not be accessible (or may only be accessed using a
different path name) on the database server machine.

You should also be aware that the postmaster and postgres servers run with the user ID of
the PostgreSQL"superuser". Note that the PostgreSQL superuser does not have to be
any particular user (e.g., a user named postgres), although many systems are installed
that way. Furthermore, the PostgreSQL superuser should definitely not
be the Unix superuser, root! It is
safest if the PostgreSQL
superuser is an ordinary, unprivileged user so far as the
surrounding Unix system is concerned. In any case, all files
relating to a database should belong to this Postgres superuser.