From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alexey Bashtanov <bashtanov(at)imap(dot)cc> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log bind parameter values on error |
Date: | 2019-02-14 20:28:42 |
Message-ID: | 20190214202842.nyx4khxsd43z4xxh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
tiny scroll-through review.
On 2019-01-28 00:15:51 +0000, Alexey Bashtanov wrote:
> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index b6f5822..997e6e8 100644
> --- a/doc/src/sgml/config.sgml
> +++ b/doc/src/sgml/config.sgml
> @@ -6274,6 +6274,23 @@ log_line_prefix = '%m [%p] %q%u(at)%d/%a '
> </listitem>
> </varlistentry>
>
> + <varlistentry id="guc-log-parameters-on-error" xreflabel="log_parameters_on_error">
> + <term><varname>log_parameters_on_error</varname> (<type>boolean</type>)
> + <indexterm>
> + <primary><varname>log_parameters_on_error</varname> configuration parameter</primary>
> + </indexterm>
> + </term>
> + <listitem>
> + <para>
> + Controls whether the statement is logged with bind parameter values.
> + It adds some overhead, as postgres will cache textual
> + representations of parameter values in memory for all statements,
> + even if they eventually do not get logged. The default is
> + <literal>off</literal>. Only superusers can change this setting.
> + </para>
> + </listitem>
> + </varlistentry>
This needs a bit of language polishing.
> @@ -31,6 +31,8 @@
> * set of parameter values. If dynamic parameter hooks are present, we
> * intentionally do not copy them into the result. Rather, we forcibly
> * instantiate all available parameter values and copy the datum values.
> + *
> + * We don't copy textual representations here.
> */
That probably needs to be expanded on. Including a comment about what
guarantees that there are no memory lifetime issues.
> - /* Free result of encoding conversion, if any */
> - if (pstring && pstring != pbuf.data)
> - pfree(pstring);
> + if (pstring)
> + {
> + if (need_text_values)
> + {
> + if (pstring == pbuf.data)
> + {
> + /*
> + * Copy textual representation to portal context.
> + */
> + params->params[paramno].textValue =
> + pstrdup(pstring);
> + }
> + else
> + {
> + /* Reuse the result of encoding conversion for it */
> + params->params[paramno].textValue = pstring;
> + }
> + }
> + else
> + {
> + /* Free result of encoding conversion */
> + if (pstring != pbuf.data)
> + pfree(pstring);
> + }
> + }
So the parameters we log here haven't actually gone through the output
function? Isn't that an issue? I mean that'll cause the contents to
differ from the non-error case, no? And differs from the binary protocol
case?
> else
> {
> + /*
> + * We do it for non-xact commands only, as an xact command
> + * 1) shouldn't have any parameters to log;
> + * 2) may have the portal dropped early.
> + */
> + Assert(current_top_portal == NULL);
> + current_top_portal = portal;
> + portalParams = NULL;
> +
"it"? ISTM the comment doesn't really stand on its own?
> +/*
> + * get_portal_bind_parameters
> + * Get the string containing parameters data, is used for logging.
> + *
> + * Can return NULL if there are no parameters in the portal
> + * or the portal is not valid, or the text representations of the parameters are
> + * not available. If returning a non-NULL value, it allocates memory
> + * for the returned string in the current context, and it's the caller's
> + * responsibility to pfree() it if needed.
> + */
> +char *
> +get_portal_bind_parameters(ParamListInfo params)
> +{
> + StringInfoData param_str;
> +
> + /* No parameters to format */
> + if (!params || params->numParams == 0)
> + return NULL;
> +
> + elog(WARNING, "params->hasTextValues=%d, IsAbortedTransactionBlockState()=%d",
> + params->hasTextValues && IsAbortedTransactionBlockState());
Err, huh?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-02-14 20:37:52 | 2019-03 CF Summary / Review - Tranche #1 |
Previous Message | Andres Freund | 2019-02-14 20:23:52 | Re: log bind parameter values on error |