log_statement

log_statement is the PostgreSQL setting that defines the type of statements logged.

Note

Fact — official short description: “Sets the type of statements logged.”

Identity

Type , Valueenum: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Valuenone, ddl, mod, all: — for non-enum types
Category , ValueReporting and Logging / What to Log: Upstream classification
Latest boot value , Valuenone: none

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–19 Beta 3	`none`	—	none

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.

Tuning advice

Tip

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

Workload	Guidance
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.
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.
Small nodes	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.

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	`ddl`	different	`ddl`
OLAP	`ddl`	different	`ddl`
CRIT	`ddl`	different	`ddl`
TINY	`ddl`	different	`ddl`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = ddl (dcs); OLAP: PG9.0–19 Beta 3 = ddl (dcs); CRIT: PG9.0–19 Beta 3 = ddl (dcs); TINY: PG9.0–19 Beta 3 = ddl (dcs). Advice, pending human review — Editorial inference: Logging DDL gives every profile a schema-change trail without paying the confidentiality and volume cost of all statements.

Common pitfalls

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.

log_duration · log_connections · log_disconnections · log_parameter_max_length · log_parameter_max_length_on_error