select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / REPORTING AND LOGGING

log_parameter_max_length_on_error

Read PG 18 manual ↗

If greater than zero, each bind parameter value reported in error messages is trimmed to this many bytes.

Type
integer
Context
user
Measured default
0 B
Unit
B
Metadata snapshot
18

Definition PG 18 manual

If greater than zero, each bind parameter value reported in error messages is trimmed to this many bytes. Zero (the default) disables including bind parameters in error messages. -1 allows bind parameters to be printed in full. If this value is specified without units, it is taken as bytes.

Non-zero values of this setting add overhead, as PostgreSQL will need to store textual representations of parameter values in memory at the start of each statement, whether or not an error eventually occurs. The overhead is greater when bind parameters are sent in binary form than when they are sent as text, since the former case requires data conversion while the latter only requires copying the string.

Measured default history
Version intervalDefault
13 – 190 B
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

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.

Operational considerations

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.

Workload guidance

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.

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.

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

Version history 3
  1. PG 17 → 18changed
  2. PG 14 → 15changed
  3. PG 12 → 13added

Related entries

Further reading

Definition snapshot: english-manuals:17a82fd39732d1fd2499f8da88f… · English manual source