log_connections

log_connections is the PostgreSQL setting that controls whether PostgreSQL logs specified aspects of connection establishment and setup.

Note

Fact — official short description: “Logs specified aspects of connection establishment and setup.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valuesuperuser-backend: Fixed when a superuser backend starts
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReporting and Logging / What to Log: Upstream classification
Latest boot value , Value"": empty string

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–17	`off`	—	off
PG18–19 Beta 3	`""`	—	empty string

How it works

In PostgreSQL 10–17, log_connections is a Boolean that logs successful connections when enabled. PostgreSQL 18 changed it to a string list whose exact options are receipt, authentication, authorization, setup_durations, and all; the empty string disables connection logging. For compatibility, on, true, yes, and 1 mean receipt,authentication,authorization, while off, false, no, and 0 mean the empty list. Failed authentication is logged regardless of this setting.

log_connections has SUPERUSER_BACKEND context: it may be selected by a superuser or a role with the appropriate SET privilege at session start, but it cannot be changed after the backend session has started. A configuration change therefore affects new sessions only.

receipt records arrival, authentication records the original identity presented by the authentication method, authorization records successful authorization with user/database/application context, and setup_durations records total setup, backend-fork, and authentication timing. log_disconnections controls session-end records separately; connection identities and topology remain sensitive log data.

Tuning advice

Tip

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

Workload	Guidance
OLTP	For routine OLTP, log only the stages required by an audit or latency question; authorization is a lower-volume successful-connection trail, while receipt and authentication add pre-authorization evidence. Add setup_durations only when connection startup latency is being investigated.
OLAP	Analytical sessions are fewer but longer, so authorization plus setup_durations can be useful for attributing expensive connection setup; do not use all merely because query volume is lower.
Small nodes	Keep the list minimal and retain failed-authentication monitoring, which is independent of this setting. Verify that log storage and redaction can safely retain original identities and application names.

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	`authorization`	different	`'authorization'`
OLAP	`authorization`	different	`'authorization'`
CRIT	`receipt,authentication,authorization`	different	`'receipt,authentication,authorization'`
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–17 unmodified, PG18–19 Beta 3 = authorization (dcs); OLAP: PG9.0–17 unmodified, PG18–19 Beta 3 = authorization (dcs); CRIT: PG9.0–17 = on (dcs), PG18–19 Beta 3 = receipt,authentication,authorization (dcs); TINY: PG9.0–19 Beta 3 unmodified. Advice, pending human review — Editorial inference: CRIT captures a fuller authentication audit trail, while PostgreSQL 18 OLTP and OLAP retain successful authorization events with lower volume; migration semantics require review.

Common pitfalls

Using setup instead of the valid PostgreSQL 18 option setup_durations.
Assuming the compatibility value on means all; it omits setup_durations and maps only to receipt, authentication, and authorization.
Expecting existing sessions to inherit a changed value even though the setting is fixed at backend startup.
Treating duplicate receipt records as attacks without accounting for clients such as psql that can probe twice, or retaining original identities without an access-control policy.

log_statement · log_duration · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error