log_connections

Definition PG 18 manual

Causes aspects of each connection to the server to be logged. The default is the empty string, '', which disables all connection logging. The following options may be specified alone or in a comma-separated list:

Disconnection logging is separately controlled by log_disconnections.

For the purposes of backwards compatibility, on, off, true, false, yes, no, 1, and 0 are still supported. The positive values are equivalent to specifying the receipt, authentication, and authorization options.

Only superusers and users with the appropriate SET privilege can change this parameter at session start, and it cannot be changed at all within a session.

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.

Operational considerations

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.

Workload guidance

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.

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.

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