Re: BUG: pg_stat_statements query normalization issues with combined queries

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Subject: Re: BUG: pg_stat_statements query normalization issues with combined queries
Date: 2016-12-26 14:27:51
Message-ID: CAMsr+YG1uY0Y_P=-RpKWevJw3wQFKBvRC0m+O-BO_2Gs95ewSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21 Dec. 2016 11:44, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:

On Tue, Dec 20, 2016 at 6:18 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> Would this approach be acceptable, or is modifying Nodes a no-go area?
>
> If it is acceptable, I can probably put together a patch and submit it.
>
> If not, I suggest to update the documentation to tell that
> pg_stat_statements does not work properly with combined queries.

I think you've found a bug, but I'm a little doubtful about your
proposed fix. However, I haven't studied the code, so I don't know
what other approach might be better.

FWIW this issue with multi-statements also causes issues with
ProcessUtility_hook. It gets the char* querytext of the whole
multistatement. Then gets invoked once for each utility command within. It
has no information about which statement text the current invocation
corresponds to.

Having a.pointer into the query text for the start and end would be good
there too. Not as good as doing away with multis entirely as a bad hack but
that's not practical for BC and protocol reasons.

BTW we should be sure the somewhat wacky semantics of multi-statements with
embedded commits are documented. I'll check tomorrow.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-12-26 14:31:39 Re: BUG: pg_stat_statements query normalization issues with combined queries
Previous Message Pavel Stehule 2016-12-26 13:24:33 Re: IF (NOT) EXISTS in psql-completion