Re: query_id, pg_stat_activity, extended query protocol

On 15.05.2024 10:24, Imseih (AWS), Sami wrote:
>> I discovered the current state of queryId reporting and found that it
>> may be unlogical: Postgres resets queryId right before query execution
>> in simple protocol and doesn't reset it at all in extended protocol and
>> other ways to execute queries.
>
> In exec_parse_message, exec_bind_message and exec_execute_message,
> the queryId is reset via pgstat_report_activity
>
>> 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.
I discovered this case a bit.
As I can see, the origin of the problem is that the exec_execute_message
report STATE_RUNNING, although ExecutorStart was called in the
exec_bind_message routine beforehand.
I'm unsure if it needs to call ExecutorStart in the bind code. But if we
don't change the current logic, would it make more sense to move
pgstat_report_query_id to the ExecutorRun routine?

--
regards, Andrei Lepikhov