Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries
| От | Craig Ringer |
|---|---|
| Тема | Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries |
| Дата | |
| Msg-id | CAMsr+YG1uY0Y_P=-RpKWevJw3wQFKBvRC0m+O-BO_2Gs95ewSw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] BUG: pg_stat_statements query normalization issues withcombined queries (Robert Haas <robertmhaas@gmail.com>) |
| Список | 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:I think you've found a bug, but I'm a little doubtful about your
> 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.
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 по дате отправления: