Alvaro Herrera <alvhe...@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