Re: [BUGS] BUG #10123: Weird entries in pg_stat_activity

On Fri, 22 Nov 2024 at 17:30, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
wrote:

>
> Patch attached.
>
+1 I think, this is much better approach than try to reset timestamp.

* Don't expose transaction time for walsenders; it confuses
* monitoring, particularly because we don't keep the time
up-to-
* date.
+ *
+ * Also, don't show transaction time for backends in the "idle"
+ * state. There are cases, like during "Describe" message
+ * handling, removing temporary relations at exit, or processing
+ * client read interrupts, where the backend remains "idle" but
+ * still sets transaction time. This can lead to incorrect
"idle"
+ * entries with non-NULL transaction times in pg_stat_activity.
To
+ * prevent these misleading entries, avoid exposing transaction
+ * time for idle backends.
*/
if (beentry->st_xact_start_timestamp != 0 &&
- beentry->st_backendType != B_WAL_SENDER)
+ beentry->st_backendType != B_WAL_SENDER &&
+ (beentry->st_state != STATE_IDLE ||
+ beentry->st_backendType != B_BACKEND))

One thing here is not 100% clear for me. As comment above stated, we don't
expose transaction time for walsenders, since it confuses monitoring. That
is clear.

- if (beentry->st_activity_start_timestamp != 0)
+ /*
+ * Don't expose query start time for idle backends for the same
+ * reasons mentioned above regarding transaction time.
+ */
+ if (beentry->st_activity_start_timestamp != 0 &&
+ (beentry->st_state != STATE_IDLE ||
+ beentry->st_backendType != B_BACKEND))

But here the comment stated "for the same reasons mentioned above" but the
condition is different. AFAICS, the walsender backend is the only one to be
affected. It's quite possible I miss something, but I expected to have,
let's say, alike conditions in this particular cases.

--
Best regards,
Maxim Orlov.