From a89ef4ff1a51940ffdf35ce295fa6a718aec025d Mon Sep 17 00:00:00 2001 From: Shihao Date: Fri, 2 Oct 2026 22:27:47 -0600 Subject: [PATCH v1] Restructure pg_blocking_pids() documentation Move the prepared transaction sentence next to the definition of hard and soft blocks, and give parallel query its own paragraph. Avoid the term "parallel lock group", which the user docs do not use. A worker PID can be passed too, so say the session's PID is reported. --- doc/src/sgml/func/func-info.sgml | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/doc/src/sgml/func/func-info.sgml b/doc/src/sgml/func/func-info.sgml index ca6d459f514..d1746609908 100644 --- a/doc/src/sgml/func/func-info.sgml +++ b/doc/src/sgml/func/func-info.sgml @@ -243,21 +243,20 @@ One server process blocks another if it either holds a lock that conflicts with the blocked process's lock request (hard block), or is waiting for a lock that would conflict with the blocked process's lock - request and is ahead of it in the wait queue (soft block). When using - parallel queries the result always lists client-visible process IDs - (that is, pg_backend_pid results) even if the - actual lock is held or awaited by a child worker process. As a result - of that, there may be duplicated PIDs in the result. When members of - the same parallel lock group block each other on a relation extension - lock (shown as lock type extend in pg_locks), the - specified process ID can also appear in the result. This does not mean - that a process blocks itself. Rather, a lock held by one member of its - parallel lock group blocks a lock request made by another member of that - group. - Also note that when a prepared transaction holds a conflicting lock, - it will be - represented by a zero process ID. + request and is ahead of it in the wait queue (soft block). A prepared + transaction that holds a conflicting lock is represented by a zero + process ID. + + + When using parallel queries the result always lists client-visible + process IDs (that is, pg_backend_pid results) + even if the actual lock is held or awaited by a child worker process. + As a result of that, there may be duplicated PIDs in the result. The + result can also contain the process ID of the blocked process's own + session. This happens when one process of a parallel query is blocked + by another process of the same query, which is only possible for + relation extension locks (lock type extend in + pg_locks). Frequent calls to this function could have some impact on database -- 2.37.1 (Apple Git-137.1)