PostgreSQL Postmaster and Background Processes

PostgreSQL has a multi-process architecture. Unlike Oracle (which is largely multi-threaded), PostgreSQL creates multiple OS processes.

1. Postmaster (Main PostgreSQL Process)

The Postmaster is the parent process of all PostgreSQL processes.

When PostgreSQL starts:

pg_ctl start

or

systemctl start postgresql

the first process created is:

Postmaster

Its responsibilities:

• Listen for client connections
• Spawn backend processes
• Start background processes
• Monitor child processes
• Perform crash recovery
• Restart failed workers

Architecture:

                    Postmaster

                         |

    -------------------------------------------------

    |          |           |          |             |

 Background  WAL       Checkpoint   Autovacuum   Backend

 Writer      Writer     Process      Workers     Sessions

---

2. Backend Processes

Every client connection gets its own backend process.

Example:

Application User-1

        |

    Backend PID 1001

Application User-2

        |

    Backend PID 1002

Application User-3

        |

    Backend PID 1003

Query:

SELECT pid,

       usename,

       application_name

FROM pg_stat_activity;

Each row corresponds to a backend process.

---

Important Background Processes

3. Background Writer (BgWriter)

Purpose:

Reduce checkpoint spikes.

When users modify data:

Shared Buffers

      ↓

Dirty Pages

These pages stay in memory.

The Background Writer gradually writes dirty pages to disk.

Without it:

Checkpoint would write everything

causing sudden I/O spikes.

View:

SELECT *

FROM pg_stat_bgwriter;

---

4. WAL Writer

One of the most important processes.

Purpose:

Flush WAL buffers to WAL files.

Flow:

INSERT/UPDATE/DELETE

       ↓

WAL Buffer

       ↓

WAL Writer

       ↓

pg_wal/

Example:

Shared Memory

      |

 WAL Buffer

      |

 WAL Writer

      |

 pg_wal files

Without WAL Writer:

Crash recovery impossible

---

5. Checkpointer

Purpose:

Create checkpoints

Checkpoint means:

Write dirty pages

to disk permanently

Flow:

Shared Buffers

      ↓

Disk Files

Checkpoint record also goes into WAL.

Benefits:

Faster crash recovery

Check settings:

SHOW checkpoint_timeout;

SHOW max_wal_size;

Monitor:

SELECT *

FROM pg_stat_bgwriter;

---

6. Autovacuum Launcher

Purpose:

Find tables needing vacuum.

It doesn't vacuum itself.

Rather:

Launcher

     ↓

Creates Workers

Architecture:

Autovacuum Launcher

        |

        +---- Worker 1

        +---- Worker 2

        +---- Worker 3

Check:

SHOW autovacuum;

---

7. Autovacuum Workers

Responsibilities:

• Remove dead tuples
• Update statistics
• Freeze old tuples
• Prevent XID wraparound

Example:

SELECT *

FROM pg_stat_progress_vacuum;

Shows currently running workers.

---

8. Statistics Collector (Older Versions)

In PostgreSQL before v14:

Stats Collector Process

maintained statistics used by:

pg_stat_activity

pg_stat_database

pg_stat_user_tables

In modern PostgreSQL versions:

Shared Memory Statistics

replaces much of the old collector architecture.

---

9. Archiver Process

Used when:

archive_mode = on

Purpose:

Copy WAL files

to archive storage

Used for:

PITR

Disaster Recovery

Check:

SELECT *

FROM pg_stat_archiver;

Example:

pg_wal

   ↓

Archive Command

   ↓

Backup Location

---

10. Startup Process

Runs during startup and recovery.

Responsibilities:

Read WAL

Replay transactions

Recover database

Example:

Crash

   ↓

Startup Process

   ↓

Replay WAL

   ↓

Consistent State

Oracle equivalent:

Instance Recovery

---

11. WAL Sender Process

Used in Streaming Replication.

Primary server:

Primary DB

   |

 WAL Sender

   |

 Network

   |

 WAL Receiver

   |

 Standby

Check:

SELECT *

FROM pg_stat_replication;

---

12. WAL Receiver Process

Runs on standby.

Purpose:

Receive WAL

from primary

Apply changes continuously.

Check:

SELECT *

FROM pg_stat_wal_receiver;

---

13. Logical Replication Launcher

Used for:

Logical Replication

Debezium

CDC

Kafka

Launches logical replication workers.

Example:

SELECT *

FROM pg_stat_subscription;

---

Shared Memory Interaction

All background processes interact with shared memory.

               Shared Memory

      ----------------------------------

      | Shared Buffers                |

      | WAL Buffers                   |

      | Lock Manager                  |

      | Proc Array                    |

      ----------------------------------

                  ^

                  |

    ------------------------------------

    |      |      |       |           |

 Backend WAL    BGW   Checkpoint  Vacuum

---

Crash Scenario Example

Suppose:

UPDATE accounts

SET balance=4000

WHERE id=1;

Step 1

Backend updates shared buffer.

Backend

  ↓

Shared Buffer

Step 2

Backend creates WAL record.

Backend

  ↓

WAL Buffer

Step 3

WAL Writer flushes WAL.

WAL Writer

  ↓

Disk

Step 4

Checkpointer eventually writes data page.

Checkpointer

   ↓

Data File

Step 5

Server crashes.

Startup Process:

Reads WAL

Replays Missing Changes

Database becomes consistent again.

---

PostgreSQL vs Oracle Background Processes

PostgreSQL	Oracle Equivalent
Postmaster	PMON + Listener coordination
Backend Process	Dedicated Server Process
WAL Writer	LGWR
Checkpointer	CKPT
Background Writer	DBWR
Startup Process	SMON Recovery
Autovacuum	No direct equivalent
WAL Sender	Data Guard Redo Transport
WAL Receiver	Managed Recovery Process
Archiver	ARCn

---

Most Common Interview Question

Explain PostgreSQL Process Architecture

Answer:

PostgreSQL uses a process-based architecture where the Postmaster acts as the parent process. For every client connection, Postmaster creates a dedicated backend process. Several background processes support database operations, including the WAL Writer for durability, Checkpointer for writing dirty pages to disk, Background Writer for smoothing I/O, Autovacuum Workers for MVCC cleanup and freeze operations, Archiver for WAL archiving, and WAL Sender/Receiver processes for streaming replication. Together they ensure performance, crash recovery, and data consistency.