Re: query_id, pg_stat_activity, extended query protocol

> >> I think the testing discussion should be moved to a different thread.
> >> What do you think?
> > See v4.
> >
> > 0001 deals with reporting queryId in exec_execute_message and
> > exec_bind_message.
> > 0002 deals with reporting queryId after a cache invalidation.
> >
> > There are no tests as this requires more discussion in a separate thread(?)
> At first, these patches look good.
> But I have a feeling of some mess here:
> queryId should be initialised at the top-level query. At the same time,
> the RevalidateCachedQuery routine can change this value in the case of
> the query tree re-validation.
> You can say that this routine can't be called from a non-top-level query
> right now, except SPI. Yes, but what about extensions or future usage?

This is a valid point. RevalidatePlanCache is forcing a
new queryId to be advertised ( 'true' as the second argument to
pgstat_report_query_id) . This means,
v4-0002-Report-new-queryId-after-plancache-re-validation.patch
will result in a non top-level queryId being advertised.

See the attached test case.

I need to think about this a bit.

--
Sami