Postgres is implemented using a
simple "process per-user" client/server model. In this model there
is one client process connected to exactly
one server process. As we don't know
per se how many connections will be
made, we have to use a master process that
spawns a new server process every time a connection is requested.
This master process is called postmaster
and listens at a specified TCP/IP port for incoming connections.
Whenever a request for a connection is detected the postmaster process spawns a new server process
called postgres. The server tasks
(postgres processes) communicate with each
other using semaphores and shared memory to ensure data integrity throughout
concurrent data access. Figure \ref{connection} illustrates the
interaction of the master process postmaster the server process postgres and a client application.

The client process can either be the psql frontend (for interactive SQL queries) or
any user application implemented using the libpg library. Note that applications implemented
using ecpg (the Postgres embedded SQL preprocessor for C) also
use this library.

Once a connection is established the client process can send a
query to the backend (server). The query
is transmitted using plain text, i.e. there is no parsing done in
the frontend (client). The server parses
the query, creates an execution plan,
executes the plan and returns the retrieved tuples to the client by
transmitting them over the established connection.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.