I wrote:
>> Table 27.4 is annoying: it could be made to work, just barely, with some
>> hacking of the column widths and a or two. But it's not stable
>> text so I have little faith in the longevity of such a solution,
>> especially if people keep on inventing long wait event names. I also
>> find it not very readable, even in a wide window. The first idea that
>> comes to mind is to split it into multiple tables, one per "Wait Event
>> Type", so that we don't need the lefthand column.
Here's an attempt at doing it that way. I think this might be a better
answer, although it's still subject to problems if anyone's logorrhea gets
any worse in naming wait conditions: "SerializablePredicateLockListLock"
is still going to force manually tweaking the column widths.
I sorted the names here, too.
regards, tom lane
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 579ccd3..64fc0e0 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -724,86 +724,15 @@ postgres 27093 0.0 0.0 30096 2752 ?Ss 11:34 0:00 postgres: ser
wait_event_type
text
The type of event for which the backend is waiting, if any;
- otherwise NULL. Possible values are:
-
-
-
- LWLock: The backend is waiting for a lightweight lock.
- Each such lock protects a particular data structure in shared memory.
- wait_event will contain a name identifying the purpose
- of the lightweight lock. (Some locks have specific names; others
- are part of a group of locks each with a similar purpose.)
-
-
-
-
- Lock: The backend is waiting for a heavyweight lock.
- Heavyweight locks, also known as lock manager locks or simply locks,
- primarily protect SQL-visible objects such as tables. However,
- they are also used to ensure mutual exclusion for certain internal
- operations such as relation extension. wait_event will
- identify the type of lock awaited.
-
-
-
-
- BufferPin: The server process is waiting to access to
- a data buffer during a period when no other process can be
- examining that buffer. Buffer pin waits can be protracted if
- another process holds an open cursor which last read data from the
- buffer in question.
-
-
-
-
- Activity: The server process is idle. This is used by
- system processes waiting for activity in their main processing loop.
- wait_event will identify the specific wait point.
-
-
-
-
- Extension: The server process is waiting for activity
- in an extension module. This category is useful for modules to
- track custom waiting points.
-
-
-
-
- Client: The server process is waiting for some activity
- on a socket from user applications, and that the server expects
- something to happen that is independent from its internal processes.
- wait_event will identify the specific wait point.
-
-
-
-
- IPC: The server process is waiting for some activity
- from another process in the server. wait_event will
- identify the specific wait point.
-
-
-
-
- Timeout: The server process is waiting for a timeout
- to expire. wait_event will identify the specific wait
- point.
-
-
-
-
- IO: The server process is waiting for a IO to complete.
- wait_event will identify the specific wait point.
-
-
-
+ otherwise NULL. See .
wait_event
text
Wait event name if backend is currently waiting, otherwise NULL.
- See for details.
+ See through
+ .
@@ -890,931 +819,1186 @@ postgres 27093 0.0 0.0 30096 2752 ?Ss 11:34 0:00 postgres: ser
-
- The pg_stat_activity view will have one row
- per server process, showing information related to
- the current activity of that process.
-
+
+ The pg_stat_activity view will have one row
+ per server process, showing information related to
+ the current activity of that process.
+
+
+
+
+The wait_event and state columns are
+independent. If a backend is in the active state,
+it may or may not be waiting on some event. If the state
+is active and wait_event is non-null, it
+means that a query is being executed, but is being blocked somewhere
+in the system.
+
+
+
+
+ Wait Event Types
+
+
+
+ Wait Event Type
+ Description
+
+
+
+
+
+ Activity
+ The server
