Re: control max length of parameter values logged

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: control max length of parameter values logged
Date: 2020-04-02 17:03:16
Message-ID: 20200402170316.GA28298@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-04-02 17:04:45 Re: backup manifests
Previous Message Daniel Verite 2020-04-02 16:58:59 Re: A bug when use get_bit() function for a long bytea string