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 7-1(a)),
which in turn starts a new backend server process
(Figure 7-1(b))
and connects the frontend process to the new server
(
Figure 7-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.
