Re: control max length of parameter values logged

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Alexey Bashtanov <bashtanov(at)imap(dot)cc>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: control max length of parameter values logged
Date: 2020-04-01 09:31:42
Message-ID: 20200401093142.GN14618@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 01, 2020 at 10:10:55AM +0100, Alexey Bashtanov wrote:
> Hi,
> > > + If greater than zero, bind parameter values reported in non-error
> > > + statement-logging messages are trimmed to no more than this many bytes.
> > Can I suggest to say:
> >
> > "Limit bind parameter values reported by non-error statement-logging messages
> > to this many bytes". Or,
> >
> > "The maximum length of bind parameter values to log with non-error
> > statement-logging messages".
> Okay I'll rephrase.
> > Could you make zero a normal value and -1 the "special" value to disable
> > trimming ?
> >
> > Setting to zero will avoid displaying parameters at all, setting to -1 wil
> > display values in full.
> I can, but then for the sake of consistency I'll have to do the same for
> log_parameter_max_length.
> Then we'll end up with two ways to enable/disable parameter logging on
> error:
> using the primary boolean setting and setting length to 0.
> One of them will require superuser privileges, the other one won't.

I guess you're referring to log_parameters_on_error.
Does it have to be SUSET ?

Or maybe log_parameters_on_error doesn't need to exist at all, and setting
log_parameter_max_length=0 can be used to disable parameter logging.

I showed up late to this thread, so let's see what others think.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-04-01 09:35:36 Re: recovery_target_action=pause with confusing hint
Previous Message Fujii Masao 2020-04-01 09:19:21 Re: Planning counters in pg_stat_statements (using pgss_store)