Section 2 of 3 · 7 minutes
See how connections become server work
Your goal
What you will be able to do
Explain how a client connection becomes work performed by a PostgreSQL backend process.
Why this matters at work
The practical reason
When a query waits or consumes resources, you need to connect the client session to the server process doing the work.
Learn
The idea in plain English
A client connects through a PostgreSQL server process. PostgreSQL gives the session a backend process with a process identifier, called a PID. That backend parses SQL, plans it, and runs it.
Backends share memory areas such as shared buffers. Shared buffers cache table and index pages, but they do not replace durable storage. PostgreSQL also runs background processes for checkpoints, WAL writing, vacuum work, and other maintenance.
Remember these points
- Each normal client session has a backend PID.
- Shared buffers cache pages used by many backends.
- Background processes perform maintenance outside client queries.
See it in SQL
Find your backend process
Link the current SQL session to its PostgreSQL process and state.
SELECT
pid,
usename AS role_name,
datname AS database_name,
application_name,
state
FROM pg_stat_activity
WHERE pid = pg_backend_pid();`pg_backend_pid()` returns the PID for your current session. Filtering by it produces one row rather than exposing unrelated activity.
The application name helps trace the session back to a service or tool. The state shows whether it is active, idle, or waiting inside a transaction.
One row for your session with its PID, role, database, application name, and current state.
Useful words
Important terms
- Backend
- The PostgreSQL server process that handles one client session.
- Shared buffers
- PostgreSQL memory used to cache data and index pages.
Quick check · Not graded
Check your understanding
What does a PostgreSQL backend PID identify?
Your progress is saved to your signed-in account.