On 2020-Mar-11, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Maybe it would make sense to always log complete parameters for error
> > cases when that feature is enabled, and have the GUC only control the
> > lengths logged for non-error cases?
>
> I could get behind that. It's a bit different from the original
> idea here, but I think it's closer to being real-world-useful.
>
> Another way to slice this up would be to have a USERSET GUC that
> controls truncation of parameter values in errors, and a separate
> SUSET GUC that controls it for the non-error statement logging
> cases. I'm not sure how much that's actually worth, but if we
> feel that truncation in error cases can be useful, that's how
> I'd vote to expose it.
Either of these ideas work for me. I think I like the latter more,
since it allows to configure truncation in all cases. (I'm not really
sure I understand why one of them must be SUSET.)
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.
I agree that truncating the value that can be disabled while not
truncating the values that cannot be disabled, is a bit silly.
I'm okay with the default being not to clip anything.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
