If greater than zero, each bind parameter value reported in error messages is trimmed to this many bytes.
At a glance
| Property | Value |
|---|---|
| Parameter | log_parameter_max_length_on_error |
| Category | Error Reporting and Logging |
| Default | (see documentation) |
| Value type | integer |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 13, 14, 15, 16, 17, 18, 19 (added in 13) |
What it does
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.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW log_parameter_max_length_on_error; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'log_parameter_max_length_on_error';.
Tuning guidance
Tune this for observability versus log volume, not for raw performance. More verbose logging helps diagnose problems but costs disk and I/O; quieter logging saves space but hides detail. Pick a level your log pipeline can store and search, and raise verbosity temporarily when investigating an incident.
Reference
PostgreSQL documentation — log_parameter_max_length_on_error.