Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit ea41b8c

Browse files
committed
Documentation improvements for pg_locks with respect to SSI.
Explain that querying pg_locks does not simultaneously lock both the normal lock manager and the predicate lock manager. Per discussion with Kevin Grittner.
1 parent 5001686 commit ea41b8c

File tree

1 file changed

+12
-7
lines changed

1 file changed

+12
-7
lines changed

doc/src/sgml/catalogs.sgml

Lines changed: 12 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -7078,13 +7078,18 @@
70787078
</para>
70797079

70807080
<para>
7081-
When the <structname>pg_locks</structname> view is accessed, the
7082-
internal lock manager data structures are momentarily locked, and
7083-
a copy is made for the view to display. This ensures that the
7084-
view produces a consistent set of results, while not blocking
7085-
normal lock manager operations longer than necessary. Nonetheless
7086-
there could be some impact on database performance if this view is
7087-
frequently accessed.
7081+
The <structname>pg_locks</structname> view displays data from both the
7082+
regular lock manager and the predicate lock manager, which are
7083+
separate systems. When this view is accessed, the internal data
7084+
structures of each lock manager are momentarily locked, and copies are
7085+
made for the view to display. Each lock manager will therefore
7086+
produce a consistent set of results, but as we do not lock both lock
7087+
managers simultaneously, it is possible for locks to be taken or
7088+
released after we interrogate the regular lock manager and before we
7089+
interrogate the predicate lock manager. Each lock manager is only
7090+
locked for the minimum possible time so as to reduce the performance
7091+
impact of querying this view, but there could nevertheless be some
7092+
impact on database performance if it is frequently accessed.
70887093
</para>
70897094

70907095
<para>

0 commit comments

Comments
 (0)