PostgreSQL Backend Process (Sunucu İşlemi / PID)

An isolated operating system worker process forked by Postmaster for each client connection to parse, plan, execute queries, and coordinate via shared memory.

Internal Architecture Breakdown

PostgreSQL operates a process-per-connection architecture rather than a threaded worker model. Each backend process maintains private virtual memory heaps (relcache, catcache, work_mem) while synchronizing via POSIX shared memory (shared_buffers, lock arrays).

Even idle backend connections consume resident memory. Critically, idle in transaction backends hold open snapshot pins that block autovacuum from reclaiming dead tuples, leading to severe table bloat. Under extreme concurrent activity, frequent snapshot updates induce ProcArrayLock cache-line contention and OS scheduler overhead.

TIP

Architectural Deep Dive: For backend memory footprint and ProcArrayLock analysis, see: PostgreSQL Connection Management: Lifecycle, Capacity, and Pooling.

Production Inspection Queries

PostgreSQL

SELECT pid, backend_type, backend_start, state, query FROM pg_stat_activity WHERE backend_type = 'client backend';

Back to Glossary