Re: control max length of parameter values logged
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Alexey Bashtanov <bashtanov@imap.cc>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2020-04-02T17:03:16Z
Lists: pgsql-hackers
On 2020-Apr-02, Alexey Bashtanov wrote:
> > > + if (log_parameter_max_length_on_error > 0)
> > > + {
> > > + /*
> > > + * We can trim the saved string, knowing that we
> > > + * won't print all of it. But we must copy at
> > > + * least two more full characters than
> > > + * BuildParamLogString wants to use; otherwise it
> > > + * might fail to include the trailing ellipsis.
> > > + */
> > > + knownTextValues[paramno] =
> > > + pnstrdup(pstring,
> > > + log_parameter_max_length_on_error
> > > + + 2 * MAX_MULTIBYTE_CHAR_LEN);
> > The comment says we need at least 2 chars, but
> > log_parameter_max_length_on_error might be 1, so I think you can either add 64
> > byte fudge factor, like before, or do Max(log_parameter_max_length_on_error, 2).
> That's the code I reused without deep analysis TBH.
> I think it's mostly for to allocate the space for the ellipsis in case it
> needs to be added,
> not to copy any actual characters, that's why we add.
More or less. If you don't add these chars, mbcliplen doesn't think
there's character there, so it ends up not adding the ellipsis. (I
don't remember why it has to be two chars rather than just one.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Improve user control over truncation of logged bind-parameter values.
- 0b34e7d307e6 13.0 landed