From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Nikita Malakhov <hukutoc(at)gmail(dot)com>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
Subject: | Re: POC: Extension for adding distributed tracing - pg_tracing |
Date: | 2024-01-02 12:14:15 |
Message-ID: | CAJ7c6TNdpcBuwPFxvgxT_nWfoSskAwBHeo+_BNwFFG_mz2rfvw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
> Overall solution looks good for me except SQL Commenter - query instrumentation
> with SQL comments is often not possible on production systems. Instead
> the very often requested feature is to enable tracing for a given single query ID,
> or several (very limited number of) queries by IDs. It could be done by adding
> SQL function to add and remove query ID into a list (even array would do)
> stored in top tracing context.
Not 100% sure if I follow.
By queries you mean particular queries, not transactions? And since
they have an assigned ID it means that the query is already executing
and we want to enable the tracking in another session, right? If this
is the case I would argue that enabling/disabling tracing for an
_already_ running query (or transaction) would be way too complicated.
I wouldn't mind enabling/disabling tracing for the current session
and/or a given session ID. In the latter case it can have an effect
only for the new transactions. This however could be implemented
separately from the proposed patchset. I suggest keeping the scope
small.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Sehrope Sarkuni | 2024-01-02 12:23:31 | Re: Password leakage avoidance |
Previous Message | Aleksander Alekseev | 2024-01-02 11:35:31 | Re: Proposal to add page headers to SLRU pages |