1.2 Architectural Fundamentals

1.2 基础架构

在深入学习之前，需要首先理解PostgreSQL基本的系统架构。明白PostgreSQL各部分之间如何交互的，对于搞明白接下来介绍的知识点至关重要。

PostgreSQL是客户端/服务器架构。一个PostgreSQL会话包含以下相关的进程：

• 服务器进程。管理数据库文件，接受并执行客户端连接请求。数据库服务器进程叫做：postgres。

• 想要进行数据库操作的客户端程序。客户端程序可以多种多样：可以是一个文本工具，一个图形化程序，一个展示数据库数据的页面，或者一个专用的数据库维护工具。有些客户端程序同PostgreSQL一起发布，但大部分是用户自己开发的。

 因为是客户端/服务器架构，所以客户端和服务器可以在不同的主机上，并通过TCP/IP通信。你必须牢记这一点，因为在客户端机器上可以访问的文件，可能并不能在服务器上访问（或者只能以不同的文件名访问）。

 PostgreSQL服务器进程可以处理多个客户端的并发连接。它通过为每一个连接“fork”一个新的进程来实现此功能。客户端与fork出来的新进程通信的时候，原postgres进程就不会再干预了。所以，postgres进程是一直在运行的，等待客户端的连接，然后fork出来的进程就随着客户端连接的断开而消逝，随着客户端的连接而新生。（当然，这是对用户透明的，这里的描述是为了用户对于PostgreSQL理解的全面性而做出的努力。）

1.2. Architectural Fundamentals

Before we proceed, you should understand the basic PostgreSQL system architecture. Understanding how the parts of PostgreSQL interact will make this chapter somewhat clearer.

In database jargon, PostgreSQL uses a client/server model. A PostgreSQL session consists of the following cooperating processes (programs):

• A server process, which manages the database files, accepts connections to the database from client applications, and performs database actions on behalf of the clients. The database server program is called postgres.

• The user's client (frontend) application that wants to perform database operations. Client applications can be very diverse in nature: a client could be a text-oriented tool, a graphical application, a web server that accesses the database to display web pages, or a specialized database maintenance tool. Some client applications are supplied with the PostgreSQL distribution; most are developed by users.

As is typical of client/server applications, the client and the server can be on different hosts. In that case they communicate over a TCP/IP network connection. You should keep this in mind, because the files that can be accessed on a client machine might not be accessible (or might only be accessible using a different file name) on the database server machine.

The PostgreSQL server can handle multiple concurrent connections from clients. To achieve this it starts (“forks”) a new process for each connection. From that point on, the client and the new server process communicate without intervention by the original postgres process. Thus, the master server process is always running, waiting for client connections, whereas client and associated server processes come and go. (All of this is of course invisible to the user. We only mention it here for completeness.)