↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

GUC Parameters / Connections and Authentication

superuser_reserved_connections

Read the PG 18 manual

Determines the number of connection “slots” that are reserved for connections by PostgreSQL superusers.

Reading PG 18current·documented in 24 of 24 versions, 7.4 to 20

Type
integer
Context
postmaster
Measured default
3
Unit
—
Metadata snapshot
18

Definition PG 18 manual

Determines the number of connection “slots” that are reserved for connections by PostgreSQL superusers. At most max_connections connections can ever be active simultaneously. Whenever the number of active concurrent connections is at least max_connections minus superuser_reserved_connections, new connections will be accepted only for superusers. The connection slots reserved by this parameter are intended as final reserve for emergency use after the slots reserved by reserved_connections have been exhausted.

The default value is three connections. The value must be less than max_connections minus reserved_connections. This parameter can only be set at server start.

Measured default history
Version intervalDefault
9.0 – 193
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source

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.

Operational considerations

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.

Workload guidance

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.

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.

SMALL: 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.

Version history 9
  1. 15 → 16 changed
  2. 11 → 12 changed
  3. 10 → 11 changed
  4. 9.6 → 10 changed
  5. 9.5 → 9.6 changed
  6. 9.0 → 9.1 changed
  7. 8.4 → 9.0 changed
  8. 8.1 → 8.2 changed
  9. 7.4 → 8.0 changed

Related entries

Further reading

Definition snapshot: english-manuals:3c3d710a1cbc9d7aa4e6c65f642… · English manual source