| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: query_id, pg_stat_activity, extended query protocol |
| Date: | 2024-09-17 23:39:17 |
| Message-ID: | 111BF5AA-F01C-4E61-959A-5A44201B2BE3@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> would help to grab a query ID. A second option I have in mind would
> be to set up an injection point that produces a NOTICE if a query ID
> is set when we end processing an execute message, then check the
> number of NOTICE messages produced as these can be predictible
> depending on the number of rows and the fetch size.. This won't fly
> far unless we can control the fetch size.
FWIW, I do like the INJECTION_POINT idea and actually mentioned something
similar up the thread [1] for the revalidate cache case, but I can see it being applied
to all the other places we expect the queryId to be set.
[1] https://www.postgresql.org/message-id/465EECA3-D98C-4E46-BBDB-4D057617DD89%40gmail.com
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2024-09-17 23:47:11 | Re: BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION |
| Previous Message | Michael Paquier | 2024-09-17 22:57:11 | Re: Custom connstr in background_psql() |