Re: control max length of parameter values logged

On Thu, Mar 12, 2020 at 12:01:24PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > The reason I'm so hot about parameter truncation is that we've seen
> > cases where customers' log files contain log lines many megabytes long
> > because of gigantic parameters; UUID arrays with tens of thousands of
> > entries, and such. Sometimes we see those in the normal "statement"
> > line because $customer interpolates into the query literal; normally the
> > "solution" is to move the params from interpolated into a parameter.
> > But if we log all parameters whole, that workaround no longer works, so
> > a way to clip is necessary.
>
> Agreed, it seems like there's a fairly compelling case for being
> able to clip.
>
> > I'm okay with the default being not to clip anything.
>
> Also agreed. It's been like it is for a long time with not that
> many complaints, so the case for changing the default behavior
> seems a bit weak.
>
> Barring other opinions, I think we have consensus here on what
> to do. Alexey, will you update your patch?

I am sorry --- I am confused. Why are we truncating or allowing control
of truncation of BIND parameter values, but have no such facility for
queries. Do we assume queries are shorter than BIND parameters, or is
it just that it is easier to trim BIND parameters than values embedded
in non-EXECUTE queries.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +