Chapter 10. Overview of PostgreSQL Architecture and Internals
In order to understand the subsequent chapters, it is important that you have a firm understanding of the overall PostgreSQL system architecture. This chapter will help you to understand how the various parts of PostgreSQL interact, and will give you an overview of the internal structure of the PostgreSQL backend.
PostgreSQL Architectural Concepts
PostgreSQL uses a simple "process-per-user" client/server model. A PostgreSQL session consists of the following cooperating UNIX processes (programs):
A supervisory daemon process (postmaster)
The user's frontend application (for example, the psql program)
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 a database cluster. (SQL92 calls this a "catalog cluster".) A frontend applications that needs to access a given database within a database cluster make calls to the library. The library then sends user requests over the network to the postmaster, which in turn starts a new backend server process and connects the frontend process to the new server. 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.
A connection is established as follows:
The frontend sends a request to postmaster via a well-known network socket.
The postmaster creates a backend server.
The frontend connects to the backend server.
Multiple connections can be established.
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 can 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 (for example, a user named "postgres"), although many systems are installed that way. In any case, all files relating to a database should belong to this PostgreSQL superuser.
 | The PostgreSQL superuser should definitely not be the Linux superuser, "root"! |