Re: query_id, pg_stat_activity, extended query protocol

Поиск
Список
Период
Сортировка
От Andrei Lepikhov
Тема Re: query_id, pg_stat_activity, extended query protocol
Дата
Msg-id ccc4eda9-79d5-4bee-9b65-3ae4b60fa871@gmail.com
обсуждение исходный текст
Ответ на Re: query_id, pg_stat_activity, extended query protocol  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: query_id, pg_stat_activity, extended query protocol
Список 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




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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: First draft of PG 17 release notes
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Direct SSL connection with ALPN and HBA rules