Clarify log_parameter_max_length docs regarding log_min_duration_statement vs log_duration
Hi,
While reviewing the log_statement_max_length patch [1]/messages/by-id/CA+E0NR4S+NC6+QHyY_vUuQZMzLhKqczMx-jJVqtjAxF6+=JwAA@mail.gmail.com, I noticed the docs
for log_parameter_max_length say:
This setting only affects log messages printed as a result of
log_statement, log_duration, and related settings.”
However, enabling only log_duration does not log bind parameter values,
so in practice log_parameter_max_length does not seem to affect messages
generated by log_duration. Bind parameters are logged, for example, when
log_min_duration_statement is set.
Given that, referencing log_duration here seems misleading. Would it be
better to mention log_min_duration_statement instead?
I've attached a patch that makes this change.
Regards,
[1]: /messages/by-id/CA+E0NR4S+NC6+QHyY_vUuQZMzLhKqczMx-jJVqtjAxF6+=JwAA@mail.gmail.com
--
Fujii Masao
Attachments:
v1-0001-doc-Fix-log_parameter_max_length-docs-to-referenc.patchapplication/octet-stream; name=v1-0001-doc-Fix-log_parameter_max_length-docs-to-referenc.patchDownload+4-4
Hi Fujii,
The current wording in the docs is misleading. +1 to the patch for
correcting it.
log_parameter_max_length only affects the "Parameters: ..." line that
appears alongside logged statements in the server log.
That line is never emitted when only log_duration is turned on. It only
shows up when log_min_duration_statement (or a sample-rate variant) is what
causes the statement to be logged.
So the change looks accurate.
(Pointer for anyone tracing it: log_parameter_max_length is read only
inside errdetail_params(), and the log_duration-
only path through check_log_duration() the return-1 arm never routes
through it.)
Two small questions:
1. log_min_duration_sample and log_transaction_sample_rate also cause
"Parameters:" lines to be emitted, and are therefore
also affected by log_parameter_max_length. "and related settings" arguably
covers them, but if we want the enumeration to be more
precise than before, would it be worth naming them explicitly? Either way
is fine just curious about the rationale.
2. This wording was introduced in 0b34e7d307e and is in every supported
branch. Should this be back patched?
Regards,
Surya Poondla
On Tue, Jul 14, 2026 at 4:05 AM surya poondla <suryapoondla4@gmail.com> wrote:
Hi Fujii,
The current wording in the docs is misleading. +1 to the patch for correcting it.
log_parameter_max_length only affects the "Parameters: ..." line that appears alongside logged statements in the server log.
That line is never emitted when only log_duration is turned on. It only shows up when log_min_duration_statement (or a sample-rate variant) is what causes the statement to be logged.
So the change looks accurate.
Thanks for the review!
1. log_min_duration_sample and log_transaction_sample_rate also cause "Parameters:" lines to be emitted, and are therefore
also affected by log_parameter_max_length. "and related settings" arguably covers them, but if we want the enumeration to be more
precise than before, would it be worth naming them explicitly? Either way is fine just curious about the rationale.
TBH I'm also fine with either approach.
2. This wording was introduced in 0b34e7d307e and is in every supported branch. Should this be back patched?
Yes, I think this should be backpatched to all supported versions.
Regards,
--
Fujii Masao
Hi Fujii,
Sounds good on both fronts.
The patch looks in a good shape, it can be committed to the codebase.
Regards,
Surya Poondla
On Thu, Jul 16, 2026 at 3:51 AM surya poondla <suryapoondla4@gmail.com> wrote:
Hi Fujii,
Sounds good on both fronts.
The patch looks in a good shape, it can be committed to the codebase.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao