Pushed with a bit of editorialization.
Great, and thanks for the fixes!
Best, Alex
Alexey Bashtanov writes:
> Please see the new version attached.
Pushed with a bit of editorialization.
regards, tom lane
Alvaro Herrera writes:
> More or less. If you don't add these chars, mbcliplen doesn't think
> there's character there, so it ends up not adding the ellipsis. (I
> don't remember why it has to be two chars rather than just one.)
I think the idea is to be sure that there's a full multibyte
On 2020-Apr-02, Alexey Bashtanov wrote:
> > > + if
> > > (log_parameter_max_length_on_error > 0)
> > > + {
> > > + /*
> > > +
Hi,
Please see the new version attached.
+If greater than zero, bind parameter values reported in non-error
+statement-logging messages are trimmed to no more than this many bytes.
+If this value is specified without units, it is taken as bytes.
+Zero disables
Thanks for updating the patch.
On Thu, Apr 02, 2020 at 01:29:04AM +0100, Alexey Bashtanov wrote:
> +If greater than zero, bind parameter values reported in non-error
> +statement-logging messages are trimmed to no more than this many
> bytes.
> +If this value is specified
Hi,
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
Justin Pryzby 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
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
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
Hi,
On Wed, Apr 01, 2020 at 01:52:48AM +0100, Alexey Bashtanov wrote:
> +++ b/doc/src/sgml/config.sgml
> + xreflabel="log_parameter_max_length">
> + log_parameter_max_length
> (integer)
> +
> + log_parameter_max_length configuration
> parameter
> +
> +
> +
Alexey Bashtanov writes:
> Sorry for the delay, please could you have a look?
Got it, will look tomorrow. (I think it's important to get this
done for v13, before we ship this behavior.)
regards, tom lane
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?
Sorry for the delay, please could you
On Sun, Mar 15, 2020 at 08:48:33PM -0300, Alvaro Herrera wrote:
> On 2020-Mar-14, Tom Lane wrote:
>
> > Bruce Momjian writes:
> > > I am sorry --- I am confused. Why are we truncating or allowing control
> > > of truncation of BIND parameter values, but have no such facility for
> > > queries.
Hi,
BIND parameter truncation is good to me.
Logs could be very hard to read due to
the very long parameters recorded.
Now, parameter is extracuted from left.
e.g. "----" to "--..."
Is not necessary from right?
e.g. "----" to
On 2020-Mar-14, Tom Lane wrote:
> Bruce Momjian writes:
> > I am sorry --- I am confused. Why are we truncating or allowing control
> > of truncation of BIND parameter values, but have no such facility for
> > queries. Do we assume queries are shorter than BIND parameters, or is
> > it just
Bruce Momjian writes:
> I am sorry --- I am confused. Why are we truncating or allowing control
> of truncation of BIND parameter values, but have no such facility for
> queries. Do we assume queries are shorter than BIND parameters, or is
> it just that it is easier to trim BIND parameters
On Thu, Mar 12, 2020 at 12:01:24PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > 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
Alvaro Herrera 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
On 2020-Mar-11, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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
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
>
Alexey Bashtanov writes:
> I personally don't think that we necessarily need to cut the values, we
> can rely on the users
> being careful when using this feature -- in the same way we trusted them
> use similarly dangerous
> log_min_duration_statement and especially log_statement for ages. At
Hello
Patch ba79cb5 (for full discussion see [1]) introduces a feature to log
bind parameter values on error,
which greatly helps to reproduce errors artificially having only server
log -- thanks everyone who
reviewed and improved it!
However, it cuts the values, as some of the reviewers
24 matches
Mail list logo
