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
