reserved_connections

reserved_connections is the PostgreSQL setting that defines the number of connection slots reserved for roles with privileges of pg_use_reserved_connections.

Note

Fact — official short description: “Sets the number of connection slots reserved for roles with privileges of pg_use_reserved_connections.”

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 , Value0: 0

Lifecycle

Fact	Value
First observed	PG16
Present in	PG16–19 Beta 3
Removed in	No
Introduction commit	`6e2775e4d4e4` — Add new GUC reserved_connections.
Commit date	2023-01-20
Discussion	thread 1

Default history

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

How it works

reserved_connections sets the number of connection slots reserved for roles with privileges of pg_use_reserved_connections. These slots become available only to roles granted pg_use_reserved_connections and sit above ordinary capacity but below superuser-only reserves.

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 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 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	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG16–19 Beta 3 unmodified; OLAP: PG16–19 Beta 3 unmodified; CRIT: PG16–19 Beta 3 unmodified; TINY: PG16–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Expecting a reload or SET to activate 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.
Sizing ordinary, reserved, and superuser-reserved slots without ensuring their sum fits max_connections.

listen_addresses · port · max_connections · superuser_reserved_connections · unix_socket_directories