Before we begin, you should understand the basic
PostgreSQL system architecture. Understanding how the
parts of PostgreSQL interact will make the next chapter
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
which in turn starts a new backend server process
Figure 7-1. How a connection is established
and connects the frontend process to the new server
From that point on, the frontend process and the backend
server communicate without intervention by the
. 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
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
You should also be aware that the postmaster and
postgres servers run with the user ID of the PostgreSQL
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
In any case, all files relating to a database should belong to
this Postgres superuser.