Re: BUG: pg_stat_statements query normalization issues with combined queries

On 26 January 2017 at 21:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com> writes:
>> One suggestion: it's currently non-obvious that ProcessUtility_hook
>> gets called with the full text of all parts of a multi-statement.
>
> OK, we can improve that ...
>
>> The same query string may be passed to multiple invocations of ProcessUtility
>> if a utility statement in turn invokes other utility statements, or if the
>> user supplied a query string containing multiple semicolon-separated
>> statements in a single protocol message. It is also possible for the query
>> text to contain other non-utility-statement text like comments, empty
>> statements, and plannable statements. Callers that use the queryString
>> should use pstmt->stmt_location and pstmt->stmt_len to extract the text for
>> the statement of interest and should guard against re-entrant invocation.
>
> Not sure about the reference to re-entrancy. It's not especially relevant
> to query texts AFAICS, and wouldn't a utility statement know darn well if
> it was doing something that could end up invoking another instance of
> itself?

The utility statement does, but the hooks don't necessarily. If you fire an

ALTER TABLE ...
ADD COLUMN ..
ADD COLUMN ..
ADD CONSTRAINT ..;

for example.

However, I was wrong to say we must guard against re-entrancy. We
should only enter ProcessUtility once with context ==
PROCESS_UTILITY_QUERY, and that's what hooks should be looking at
rather than keeping track of re-entrant invocations.

So perhaps:

"The same query string may be passed to multiple invocations of
ProcessUtility if a utility statement invokes subcommands (e.g. ALTER
TABLE), in which case context will be set to
PROCESS_UTILITY_SUBCOMMAND, or if the user supplied a query string
containing multiple semicolon-separated statements in a single
protocol message. It is also possible for the query text to contain
other non-utility-statement text like comments, empty statements, and
plannable statements that don't pass through ProcessUtility. Hooks
that use the queryString should use pstmt->stmt_location and
pstmt->stmt_len to extract the text for the statement of interest and
should pay attention to the context to avoid repeatedly handling the
same query string in subcommands."

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services