Re: query_id, pg_stat_activity, extended query protocol

On Fri, Jul 26, 2024 at 02:39:41PM +0200, Anthonin Bonnefoy wrote:
> For the tests, there are limited possibilities to check whether a
> query_id has been set correctly.
> - Checking pg_stat_activity is not possible in the regress tests as
> you need a second session to check the reported query_id.
> - pg_stat_statements can be used indirectly but you're limited to how
> pgss uses query_id. For example, it doesn't rely on queryId in
> ExecutorRun.
>
> A possible solution I've been thinking of is to use a test module. The
> module will assert on whether the queryId is set or not in parse, plan
> and executor hooks. It will also check if the queryId reported in
> pgstat matches the queryId at the root level.

FWIW, I was more thinking in the lines of a TAP test with
PostgreSQL::Test::BackgroundPsql to hold the sessions around while
doing pg_stat_activity lookups.

Using a test module like what you have is really tempting to rely on
the hooks for the work, that's something I'll try to think about more.

We could perhaps push the query ID into a table saving the state that
gets queried in the SQL test, using only assertions is not enough as
this makes the test moot with assertions disabled. And actually,
there may be a point in just pushing safety assertions to be in the
core backend code, as a HEAD-only improvement.
--
Michael