PostgreSQL Architecture
How Connections are
established:
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 do not know ahead
of time 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 postgres and listens at a specified TCP/IP port for incoming
connections. Whenever a request for a connection is detected the postgres
process spawns a new server process. The server tasks communicate with each
other using semaphores and shared memory to ensure data integrity throughout
concurrent data access.
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 rows to the client by transmitting them over the
established connection.
PostgreSQL Architecture:
Libpq:
Libpq is the C application
programmer's interface to PostgreSQL. Libpq is a set of library functions that
allow client programs to pass queries to the PostgreSQL backend server and to
receive the results of these queries.
Libpq is also the underlying engine
for several other PostgreSQL application interfaces, including those written
for C++, Perl, Python, Tcl and ECPG
Postmaster:
When a client request for
connection to the database, firstly request is hit to Postmaster daemon
process. After performing authentication and authorization it forks one new
backend server process (postgres). Henceforth, the frontend process and the
backend server communicate directly without intervention by the postmaster.
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 postgres process exists for
every open database session. Once authenticated with user connection, it
directly connects with shared memory.
Comments
Post a Comment