2 1.2. Architectural Fundamentals #
4 Before we proceed, you should understand the basic PostgreSQL system
5 architecture. Understanding how the parts of PostgreSQL interact will
6 make this chapter somewhat clearer.
8 In database jargon, PostgreSQL uses a client/server model. A PostgreSQL
9 session consists of the following cooperating processes (programs):
10 * A server process, which manages the database files, accepts
11 connections to the database from client applications, and performs
12 database actions on behalf of the clients. The database server
13 program is called postgres.
14 * The user's client (frontend) application that wants to perform
15 database operations. Client applications can be very diverse in
16 nature: a client could be a text-oriented tool, a graphical
17 application, a web server that accesses the database to display web
18 pages, or a specialized database maintenance tool. Some client
19 applications are supplied with the PostgreSQL distribution; most
20 are developed by users.
22 As is typical of client/server applications, the client and the server
23 can be on different hosts. In that case they communicate over a TCP/IP
24 network connection. You should keep this in mind, because the files
25 that can be accessed on a client machine might not be accessible (or
26 might only be accessible using a different file name) on the database
29 The PostgreSQL server can handle multiple concurrent connections from
30 clients. To achieve this it starts (“forks”) a new process for each
31 connection. From that point on, the client and the new server process
32 communicate without intervention by the original postgres process.
33 Thus, the supervisor server process is always running, waiting for
34 client connections, whereas client and associated server processes come
35 and go. (All of this is of course invisible to the user. We only
36 mention it here for completeness.)