Before we proceed, you should understand the basic PostgreSQL system architecture. Understanding how the parts of PostgreSQL interact will make this chapter somewhat clearer.
PostgreSQL uses a client/server model. A PostgreSQL session consists of the following cooperating processes:
A server process, which manages the database files, accepts connections from client applications and performs actions on the database on behalf of the clients. The database server program is called postmaster.
The user's client (frontend) application that wants to perform database operations. Client applications can be very diverse in nature: they could be text-oriented tools, graphical applications, web servers that accesses the database to display web pages, or specialized database maintenance tools.
The client and the server can be on different hosts, in which case they communicate over a TCP/IP network connection. You should keep this in mind because the files that can be accessed on the 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. For that purpose 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 postmaster process. Thus, the postmaster 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.