log_parameter_max_length_on_error

log_parameter_max_length_on_error is the PostgreSQL setting that defines the maximum length in bytes of data logged for bind parameter values when logging statements, on error.

Note

Fact — official short description: “Sets the maximum length in bytes of data logged for bind parameter values when logging statements, on error.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , ValueB: Raw unit
Range , Value-1 – 1073741823: 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 , Value0: 0 B

Lifecycle

Fact	Value
First observed	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`0b34e7d307e6` — Improve user control over truncation of logged bind-parameter values.
Commit date	2020-04-02
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG13–19 Beta 3	`0`	`B`	0 B

How it works

log_parameter_max_length_on_error controls Bind values included in error reports. Zero, the default, suppresses them; -1 permits complete values; a positive byte count truncates each textual value to that limit.

For any nonzero value PostgreSQL must preserve textual parameter representations at the start of every statement in case an error occurs. That overhead is paid even by successful statements, and binary parameters require conversion rather than a simple text copy.

It is a USER-context session setting and is independent of log_parameter_max_length, so an application can accidentally expose values on errors even when normal statement logging suppresses them. Error detail, access, redaction, and retention must be reviewed together.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Keep zero unless error diagnosis specifically requires bind values. Any nonzero value adds conversion and retained-memory work to every statement, so prefer a bounded positive value scoped by role, database, or session.
OLAP	Use a bounded positive limit only during controlled diagnosis of parameterized analytical jobs. Budget textual conversion and retained parameter memory for successful statements as well as failures.
Small nodes	Prefer zero. If error-path binds are essential, choose a short limit, scope it narrowly, and verify both memory overhead and secret-redaction policy before enabling it.

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	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Assuming the conversion and memory cost is paid only when a statement fails; every statement pays it when the value is nonzero.
Using -1 and exposing complete secrets or large payloads in error reports.
Ignoring textual conversion cost for binary Bind values and retained representations for successful statements.
Assuming log_parameter_max_length also protects error paths; the two limits are independent.

log_statement · log_duration · log_connections · log_disconnections · log_parameter_max_length