On 26/02/2025 22:00, Sami Imseih wrote:
If we do need to document anything, which I am not convinced we should,
it should be more generic.

Thanks for the feedback, I've attached a v2 patch which has wording that's a bit more generic.

It's also worth noting that pg_locks already has a full paragraph explaining inconsistencies, so in my opinion it's worth it at least mentioning something similar here for pg_stat_activity.


Best regards,

Alex Friedman
From fbbfc623e16ed97176c0ccf0ebc534d118e9f252 Mon Sep 17 00:00:00 2001
From: Alex Friedman <alex...@gmail.com>
Date: Wed, 26 Feb 2025 19:59:59 +0200
Subject: [PATCH v2] Clarify possibility of ephemeral discrepancies between
 state and wait_event in pg_stat_activity.

---
 doc/src/sgml/monitoring.sgml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 9178f1d34ef..de49769d407 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1016,7 +1016,11 @@ postgres   27093  0.0  0.0  30096  2752 ?        Ss   
11:34   0:00 postgres: ser
     it may or may not be <literal>waiting</literal> on some event.  If the 
state
     is <literal>active</literal> and <structfield>wait_event</structfield> is 
non-null, it
     means that a query is being executed, but is being blocked somewhere
-    in the system.
+    in the system. To keep the reporting low-overhead, the system uses very 
lightweight
+    synchronization. As a result, ephemeral discrepancies between the view's 
columns,
+    for example between <structfield>wait_event</structfield> and
+    <structfield>state</structfield>, or between 
<structfield>state</structfield> and
+    <structfield>query_id</structfield>, are possible by nature.
    </para>
   </note>
 
-- 
2.41.0

Reply via email to