| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Alexey Bashtanov <bashtanov(at)imap(dot)cc>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: control max length of parameter values logged |
| Date: | 2020-03-11 21:56:28 |
| Message-ID: | 27700.1583963788@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hugh McMaster | 2020-03-11 22:19:35 | Re: [PATCH] Use PKG_CHECK_MODULES to detect the libxml2 library |
| Previous Message | Alvaro Herrera | 2020-03-11 21:17:32 | Re: control max length of parameter values logged |