Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries
Date
Msg-id CAMsr+YG1uY0Y_P=-RpKWevJw3wQFKBvRC0m+O-BO_2Gs95ewSw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On 21 Dec. 2016 11:44, "Robert Haas" <robertmhaas@gmail.com> wrote:
On Tue, Dec 20, 2016 at 6:18 AM, Fabien COELHO <coelho@cri.ensmp.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.

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] IF (NOT) EXISTS in psql-completion
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries