PostgreSQL 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 PostgreSQL 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.
