From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
Cc: | 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-05-15 13:29:00 |
Message-ID: | ccc4eda9-79d5-4bee-9b65-3ae4b60fa871@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15/5/2024 12:09, Michael Paquier wrote:
> On Wed, May 15, 2024 at 03:24:05AM +0000, Imseih (AWS), Sami wrote:
>>> I think we should generally report it when the backend executes a job
>>> related to the query with that queryId. This means it would reset the
>>> queryId at the end of the query execution.
>>
>> When the query completes execution and the session goes into a state
>> other than "active", both the query text and the queryId should be of the
>> last executed statement. This is the documented behavior, and I believe
>> it's the correct behavior.
>>
>> If we reset queryId at the end of execution, this behavior breaks. Right?
>
> Idle sessions keep track of the last query string run, hence being
> consistent in pg_stat_activity and report its query ID is user
> friendly. Resetting it while keeping the string is less consistent.
> It's been this way for years, so I'd rather let it be this way.
Okay, that's what I precisely wanted to understand: queryId doesn't have
semantics to show the job that consumes resources right now—it is mostly
about convenience to know that the backend processes nothing except
(probably) this query.
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-05-15 13:33:33 | Re: Direct SSL connection with ALPN and HBA rules |
Previous Message | Amit Kapila | 2024-05-15 13:13:51 | Re: First draft of PG 17 release notes |