Re: [BUGS] BUG #10123: Weird entries in pg_stat_activity - Mailing list pgsql-bugs
| From | Maxim Orlov |
|---|---|
| Subject | Re: [BUGS] BUG #10123: Weird entries in pg_stat_activity |
| Date | |
| Msg-id | CACG=ezZbKP_WpQeEV=104N7Ate7GfzBqYqqEFH5nW2bew7aB-Q@mail.gmail.com Whole thread Raw |
| In response to | BUG #10123: Weird entries in pg_stat_activity (maxim.boguk@gmail.com) |
| List | pgsql-bugs |
On Fri, 22 Nov 2024 at 17:30, Fujii Masao <masao.fujii@oss.nttdata.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))
* 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))
+ /*
+ * 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.
pgsql-bugs by date:
Previous
From: Thomas MunroDate:
Subject: Re: Detection of hadware feature => please do not use signal