Re: control max length of parameter values logged

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:17:32
Message-ID: 20200311211732.GA2855@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Mar-10, Tom Lane wrote:

> I agree that something ought to be done here, but I'm not sure that
> this is exactly what. It appears to me that there are three related
> but distinct behaviors under discussion:
>
> 1. Truncation of bind parameters returned to clients in error message
> detail fields.
> 2. Truncation of bind parameters written to the server log in logged
> error messages.
> 3. Truncation of bind parameters written to the server log in non-error
> statement logging actions (log_statement and variants).
>
> Historically we haven't truncated any of these, I believe. As of
> ba79cb5dc we forcibly truncate #1 and #2 at 64 bytes, but not #3.
> Your patch proposes to provide a SUSET GUC that controls the
> truncation length for all 3.

The reason I didn't change the other uses was precisely that it was
established behavior, but my opinion was that truncating them would
be better, now that we have code to handle doing so.

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?

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-11 21:56:28 Re: control max length of parameter values logged
Previous Message Devrim Gunduz 2020-03-11 21:07:32 Re: v13 latest snapshot build error