superuser_reserved_connections

superuser_reserved_connections is the PostgreSQL setting that defines the number of connection slots reserved for superusers.

Note

Fact — official short description: “Sets the number of connection slots reserved for superusers.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value—: Raw unit
Range , Value0 – 262143: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueConnections and Authentication / Connection Settings: Upstream classification
Latest boot value , Value3: 3

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.0–19 Beta 3	`3`	—	3

How it works

superuser_reserved_connections sets the number of connection slots reserved for superusers. These slots are usable only after ordinary and reserved_connections capacity is exhausted, preserving an emergency path for superusers.

superuser_reserved_connections is a POSTMASTER-context setting: PostgreSQL reads it during server startup, and a configuration reload or session SET cannot activate a new value.

reserved_connections and superuser_reserved_connections carve privileged tiers from max_connections; poolers, monitoring, replication, maintenance, and failover must all fit the same total backend budget.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Size superuser_reserved_connections inside max_connections from the number of independent emergency actors, pooler behavior, and failover operations. Test that ordinary saturation still leaves usable administrative access.
OLAP	Reserve enough slots for control, monitoring, and cancellation around heavy analytical sessions, but do not let reserves consume an excessive share of a deliberately small backend pool.
Small nodes	Keep superuser_reserved_connections modest relative to max_connections while preserving at least one tested emergency path; reserved slots are capacity unavailable to ordinary clients at saturation.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	`10`	different	`10`
OLAP	`10`	different	`10`
CRIT	`10`	different	`10`
TINY	`10`	different	`10`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 10 (dcs); OLAP: PG9.0–19 Beta 3 = 10 (dcs); CRIT: PG9.0–19 Beta 3 = 10 (dcs); TINY: PG9.0–19 Beta 3 = 10 (dcs). Advice, pending human review — Editorial inference: Ten emergency slots preserve more operational headroom than upstream for monitoring, repair, and failover on a pooler-fronted service.

Common pitfalls

Expecting a reload or SET to activate superuser_reserved_connections, although it requires a controlled server restart.
Counting reserved slots outside max_connections even though every tier consumes the same total ceiling.
Reserving too little for incident response or so much that ordinary application capacity collapses at saturation.
Changing superuser_reserved_connections globally without a rollback plan and a client or operational compatibility test.

listen_addresses · port · max_connections · reserved_connections · unix_socket_directories