diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-04-02 15:04:51 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-04-02 15:04:51 -0400 |
commit | 0b34e7d307e6a142ee94800e6d5f3e73449eeffd (patch) | |
tree | 44e10638357e0c9447cec80e4d94421855083cdf /src/backend/access/gist/gistbuildbuffers.c | |
parent | 2c220ca46f3f6de0611367312bec0daef99b29eb (diff) | |
download | postgresql-0b34e7d307e6a142ee94800e6d5f3e73449eeffd.tar.gz postgresql-0b34e7d307e6a142ee94800e6d5f3e73449eeffd.zip |
Improve user control over truncation of logged bind-parameter values.
This patch replaces the boolean GUC log_parameters_on_error introduced
by commit ba79cb5dc with an integer log_parameter_max_length_on_error,
adding the ability to specify how many bytes to trim each logged
parameter value to. (The previous coding hard-wired that choice at
64 bytes.)
In addition, add a new parameter log_parameter_max_length that provides
similar control over truncation of query parameters that are logged in
response to statement-logging options, as opposed to errors. Previous
releases always logged such parameters in full, possibly causing log
bloat.
For backwards compatibility with prior releases,
log_parameter_max_length defaults to -1 (log in full), while
log_parameter_max_length_on_error defaults to 0 (no logging).
Per discussion, log_parameter_max_length is SUSET since the DBA should
control routine logging behavior, but log_parameter_max_length_on_error
is USERSET because it also affects errcontext data sent back to the
client.
Alexey Bashtanov, editorialized a little by me
Discussion: https://postgr.es/m/b10493cc-a399-a03a-67c7-068f2791ee50@imap.cc
Diffstat (limited to 'src/backend/access/gist/gistbuildbuffers.c')
0 files changed, 0 insertions, 0 deletions