Re: BUG: pg_stat_statements query normalization issues with combined queries
Craig Ringer <craig.ringer@2ndquadrant.com>
From: Craig Ringer <craig.ringer@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Fabien COELHO <coelho@cri.ensmp.fr>
Date: 2016-12-26T14:27:51Z
Lists: 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.
Commits
-
Teach contrib/pg_stat_statements to handle multi-statement commands better.
- 83f2061dd037 10.0 landed
-
Change representation of statement lists, and add statement location info.
- ab1f0c822571 10.0 landed
-
Revert my bad decision of about a year ago to make PortalDefineQuery
- 1591fcbec77f 8.4.0 cited