Re: query_id, pg_stat_activity, extended query protocol

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: query_id, pg_stat_activity, extended query protocol
Дата
Msg-id ZqQk0WHN8EMBEai9@paquier.xyz
обсуждение исходный текст
Ответ на Re: query_id, pg_stat_activity, extended query protocol  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Список pgsql-hackers
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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Use pgBufferUsage for block reporting in analyze
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_upgrade failing for 200+ million Large Objects