Re: query_id, pg_stat_activity, extended query protocol

Sorry for the late reply on this thread.

On 14/8/2024 23:05, Imseih (AWS), Sami wrote:
> There are no tests as this requires more discussion in a separate thread(?)
> Unfortunately, TAP tests don't allow us to keep a connection and
> manually permutate the order of queries sent to different connections.
> But isolation tests are designed to do so. Of course, they aren't the
> best if you need to compare values produced by various queries but see a
> clumsy sketch doing that in the attachment.

It would be nice to use isolation tests as you have, those type of tests
don't support psql meta-commands. We need \parse, \bind, \bind_named
to test queryId for queries issued through extended query protocol.

With TAP tests we can use query_until in BackgroundPsql to have one
connection issue a command and another connection track the # of distinct
queryIds expected. See the 007_query_id.pl of an example TAP test that
could be added under test_misc.

An INJECTION_POINT can also be added right before we call pgstat_report_query_id
in plancache.c. This will allow us to test when we expect the queryId to
change after a cache revalidation. Thoughts?

> Also, while writing the test, I found out that now, JumbleQuery takes
> into account constants of the A_Const node, and calls of the same
> prepared statement with different parameters generate different
> query_id. Is it a reason to introduce JumbleQuery options and allow
> different logic of queryid generation?

Can you start a new thread for this prepared statement scenario?

--
Sami