Re: control max length of parameter values logged - Mailing list pgsql-hackers

From Tom Lane
Subject Re: control max length of parameter values logged
Date
Msg-id 14318.1585752708@sss.pgh.pa.us
Whole thread Raw
In response to Re: control max length of parameter values logged  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: control max length of parameter values logged  (Alexey Bashtanov <bashtanov@imap.cc>)
List pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> On Wed, Apr 01, 2020 at 10:10:55AM +0100, Alexey Bashtanov wrote:
>>> Could you make zero a normal value and -1 the "special" value to disable
>>> trimming ?

>> 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.

I think Justin's got a point: defining zero this way is weirdly
inconsistent.  -1, being clearly outside the domain of possible
length limits, makes more sense as a marker for "don't trim".

Alexey's right that having a separate boolean flag is pointless, but
I think we could just drop the boolean; we haven't shipped that yet.
The privilege argument seems irrelevant to me.  We already decided
that the plan is (a) SUSET for non-error statement logging purposes and
(b) USERSET for logging caused by errors, and that would have to apply
to length limits as well as enable/disable ability.  Otherwise a user
could pretty effectively disable logging by setting the length to 1.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Less-silly selectivity for JSONB matching operators
Next
From: Andres Freund
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.