Today, we transition from being mere users of a database to becoming its architects. We begin our journey at the front door of the engine. In Lesson 1.1, we explore how PostgreSQL greets the world, manages its workforce, and maintains order in a chaotic environment of concurrent requests.

The Client/Server Model and the Postmaster

The Metropolitan Hotel Allegory

To understand the PostgreSQL Process Model, imagine a prestigious, high-capacity hotel: The Postgres Grand.

When a guest (the Client) arrives at the front door, they don't immediately walk into the kitchen to cook their own meal or into the basement to move their own luggage. Instead, they are met by the Head Concierge—the Postmaster.

The Postmaster does not serve the guest personally. If he did, the line at the front door would stretch for miles while he was busy in a guest’s room. Instead, the Postmaster performs a specialized "cloning" maneuver. For every guest that arrives, he hires a new, dedicated Bellhop (a Backend Process) to handle that guest's specific needs until they check out.

The Postmaster: The Grand Orchestrator

At the heart of any running PostgreSQL instance is a single supervisor process, historically called the Postmaster, though the modern binary is simply named postgres.

As detailed in the source code at src/backend/postmaster/postmaster.c, this process is the first to start and the last to die. Its primary responsibilities include:

• Initialization: Allocating the Shared Memory segments.
• Listen/Bind: Opening the network socket (typically port 5432) to listen for incoming Frontend connections.
• Process Management: Spawning and monitoring all other background processes.

The Fork/Exec Model

PostgreSQL utilizes a process-based architecture rather than a thread-based one. When a connection request is validated, the Postmaster calls the Unix system function fork().

• The fork(): This creates an exact copy of the Postmaster process. This "child" process becomes the Backend Process (or Session).
• Memory Isolation: Because these are separate processes, if one Backend Process crashes due to a memory error, it is much less likely to take down the entire database cluster. Each process has its own Private Memory (including work_mem), which we will discuss in Chapter 9.
• The Trade-off: Creating a full process is "expensive" in terms of OS overhead compared to creating a thread. This is why PostgreSQL handles thousands of connections differently than a thread-per-request engine like MySQL.

If you read the comments in postmaster.c, the core team explains that this model was chosen for robustness. In a database, data integrity is paramount; the isolation provided by process boundaries is a safety net.

The Backend Process (The Bellhop)

Once the fork is complete, the Postmaster goes back to the front door to wait for the next guest. The Backend Process now takes over the conversation with the Client.

This process is responsible for:

1. Receiving SQL strings from the client.
2. Running those strings through the Parser, Planner, and Executor.
3. Accessing the Shared Buffer Pool to read or write data.
4. Returning the final Result Set to the client.

The Backend Process lives exactly as long as the database connection. When the client sends a DISCONNECT or closes the socket, the Backend Process terminates.

The Scaling Bottleneck: Connection Pooling

Because the fork/exec model is resource-intensive, a "Connection Storm" (thousands of people trying to check into the hotel at once) can overwhelm the Postmaster and the OS kernel.

To solve this, we use Connection Pooling (e.g., PgBouncer).

• The Metaphor: Instead of hiring a new Bellhop for every guest, the hotel keeps a standing staff of 50 elite workers. Guests wait in a small line, and as soon as one worker is done with a task, they immediately help the next guest in line.
• The Technical Reality: A pooler maintains a "warm" set of established connections to the database, handing them off to applications as needed, drastically reducing the frequency of fork() calls.

Summary

• PostgreSQL follows a Client/Server Model using a Process-based architecture.
• The Postmaster (postgres) is the supervisor that listens for connections and manages the lifecycle of the cluster.
• For every connection, the Postmaster performs a fork() to create a dedicated Backend Process.
• Process Isolation provides high stability and fault tolerance but introduces higher overhead than threading.
• Connection Pooling is a critical architectural layer used to mitigate the costs of the process-per-connection model in high-throughput environments.

Synthesis

Imagine the Postmaster decides to go on strike because he is tired of "cloning himself" (forking) for every minor request. He proposes a "Self-Service" model where clients must walk into the Shared Memory themselves to find their data.

Based on what you know about memory isolation and the role of the Backend Process, describe the most catastrophic (or hilarious) thing that would happen within five minutes of the Postmaster stepping away from the door? Comment your answer in a few sentences.