log_statement

Definition PG 18 manual

Controls which SQL statements are logged. Valid values are none (off), ddl, mod, and all (all statements). ddl logs all data definition statements, such as CREATE, ALTER, and DROP statements. mod logs all ddl statements, plus data-modifying statements such as INSERT, UPDATE, DELETE, TRUNCATE, and COPY FROM. PREPARE, EXECUTE, and EXPLAIN ANALYZE statements are also logged if their contained command is of an appropriate type. For clients using extended query protocol, logging occurs when an Execute message is received, and values of the Bind parameters are included (with any embedded single-quote marks doubled).

The default is none. Only superusers and users with the appropriate SET privilege can change this setting.

How it works

log_statement selects none, ddl, mod, or all. ddl logs data-definition commands; mod adds data-changing commands; all logs every statement that reaches the logging point. PREPARE, EXECUTE, and EXPLAIN ANALYZE follow the contained command's class.

With the extended query protocol, logging occurs when Execute is received and includes Bind parameter values. Even all does not log a simple statement that fails basic parsing, nor an extended-protocol statement that fails before Execute during parse analysis or planning; log_min_error_statement is required for those error paths.

It is a SUPERUSER-context session setting. Statement text and Bind values can expose personal data, tokens, and even plaintext passwords, so selection, access, redaction, transport, and retention must be treated as a security control as well as an observability choice.

Operational considerations

Assuming all captures syntax errors or extended-protocol failures before Execute; use log_min_error_statement for those paths.

Forgetting that extended-protocol Execute logging includes Bind parameter values.

Logging SQL that contains plaintext passwords, bearer tokens, personal data, or application secrets without redaction and strict access controls.

Enabling mod or all cluster-wide without bounding log throughput, disk, shipping, and retention.

Workload guidance

OLAP: Use a role- or session-scoped window for analytical troubleshooting rather than all cluster-wide. Long generated SQL and large Bind values can dominate logs and expose source data.

OLTP: Keep none or ddl as the routine OLTP baseline and use duration thresholds or sampling for query performance. Before enabling mod/all, test volume and a concrete redaction/access policy for SQL text and Bind values.

SMALL: Prefer ddl or targeted thresholds; all can overwhelm disk and reveal secrets even on a quiet node. Keep log_min_error_statement configured for syntax/parse failures that log_statement misses.