Before we proceed, you should understand the basic
PostgreSQL system architecture.
Understanding how the parts of PostgreSQL interact will make this chapter
somewhat clearer.

In database jargon, PostgreSQL uses a client/server model. A
PostgreSQL session consists of
the following cooperating processes (programs):

A server process, which manages the database files,
accepts connections to the database from client applications,
and performs database actions on behalf of the clients. The
database server program is called postgres.

The user's client (frontend) application that wants to
perform database operations. Client applications can be very
diverse in nature: a client could be a text-oriented tool, a
graphical application, a web server that accesses the
database to display web pages, or a specialized database
maintenance tool. Some client applications are supplied with
the PostgreSQL distribution;
most are developed by users.

As is typical of client/server applications, the client and
the server can be on different hosts. In that case they
communicate over a TCP/IP network connection. You should keep
this in mind, because the files that can be accessed on a client
machine might not be accessible (or might only be accessible
using a different file name) on the database server machine.

The PostgreSQL server can
handle multiple concurrent connections from clients. To achieve
this it starts ("forks") a new process
for each connection. From that point on, the client and the new
server process communicate without intervention by the original
postgres process. Thus, the master
server process is always running, waiting for client connections,
whereas client and associated server processes come and go. (All
of this is of course invisible to the user. We only mention it
here for completeness.)