Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2020-Mar-11, Tom Lane wrote:
>> 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.)
We generally suppose that GUCs that control statement logging should be
SUSET, so that unprivileged users don't get to hide their activity from
the log. On the other hand, I think it's okay for error logging (as
opposed to statement tracing) to be under user control, because the user
can simply avoid or trap an error if he doesn't want it to be logged.
> 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?
regards, tom lane