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

A supervisory daemon process (postmaster),

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

the 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 an
installation or site. Frontend applications that wish to access a
given database within an installation make calls to the library.
The library sends user requests over the network to the postmaster
(How a connection
is established(a)), which in turn starts a new backend server
process (How a
connection is established(b))

and connects the frontend process to the new server
(How a connection
is established(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
requests, whereas frontend and backend processes come and go. The
libpq library allows a single frontend to
make multiple connections to backend processes. However, the
frontend application is still a single-threaded process.
Multithreaded frontend/backend connections are not currently
supported in libpq. 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 filename) on
the database server machine. You should also be aware that the
postmaster and postgres servers run with the user-id of the
Postgres "superuser." Note that the Postgres superuser does not
have to be a special user (e.g., a user named "postgres").
Furthermore, the Postgres superuser should definitely not be the
UNIX superuser, "root"! In any case, all files relating to a
database should belong to this Postgres superuser.