Hi,
On 2024-07-04 14:54:01 +0900, Fujii Masao wrote:
> @@ -515,6 +515,17 @@ ProcessClientReadInterrupt(bool blocked)
> /* Check for general interrupts that arrived before/while reading */
> CHECK_FOR_INTERRUPTS();
>
> + /*
> + * Reset statement_timestamp() to 0 so that ProcessCatchupInterrupt()
> + * and ProcessNotifyInterrupt() will set pg_stat_activity.xact_start
> + * to NULL when they start new transaction. Otherwise, xact_start
> + * could be set to statement_timestamp() that may indicate the
> + * timestamp of the last query executed, while the backend's state
> + * remains "idle," leading to incorrect "idle" entries with non-NULL
> + * xact_start in pg_stat_activity.
> + */
> + ResetCurrentStatementStartTimestamp();
> +
> /* Process sinval catchup interrupts, if any */
> if (catchupInterruptPending)
> ProcessCatchupInterrupt();
This seems odd to me. ProcessClientReadInterrupt() can be called a lot, why do
we need to reset the statement start timestamp even if nothing is happening here?
> @@ -2598,6 +2609,8 @@ exec_describe_statement_message(const char *stmt_name)
> {
> CachedPlanSource *psrc;
>
> + pgstat_report_activity(STATE_RUNNING, NULL);
> +
> /*
> * Start up a transaction command. (Note that this will normally change
> * current memory context.) Nothing happens if we are already in one.
> @@ -2692,6 +2705,8 @@ exec_describe_portal_message(const char *portal_name)
> {
> Portal portal;
>
> + pgstat_report_activity(STATE_RUNNING, NULL);
> +
> /*
> * Start up a transaction command. (Note that this will normally change
> * current memory context.) Nothing happens if we are already in one.
Calls to pgstat_report_activity() aren't exactly free. This substantially
increases the number of calls to it for common workloads. There got to be a
more targeted way of dealing with this.
Greetings,
Andres Freund
