postgres.git / summary / log / commit / refs
commit eb03cff8208aa959aabb91aaac0e21fc88966409
Author: Robert Haas <rhaas@postgresql.org>
Date: Fri Jun 24 20:06:57 2011 +0000
First released in: 9.2.0, 9.1.0
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.
doc/src/sgml/catalogs.sgml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 7a380ce2f94..713ee25939e 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -7085,13 +7085,18 @@
</para>
<para>
- When the <structname>pg_locks</structname> view is accessed, the
- internal lock manager data structures are momentarily locked, and
- a copy is made for the view to display. This ensures that the
- view produces a consistent set of results, while not blocking
- normal lock manager operations longer than necessary. Nonetheless
- there could be some impact on database performance if this view is
- frequently accessed.
+ The <structname>pg_locks</structname> view displays data from both the
+ regular lock manager and the predicate lock manager, which are
+ separate systems. When this view is accessed, the internal data
+ structures of each lock manager are momentarily locked, and copies are
+ made for the view to display. Each lock manager will therefore
+ produce a consistent set of results, but as we do not lock both lock
+ managers simultaneously, it is possible for locks to be taken or
+ released after we interrogate the regular lock manager and before we
+ interrogate the predicate lock manager. Each lock manager is only
+ locked for the minimum possible time so as to reduce the performance
+ impact of querying this view, but there could nevertheless be some
+ impact on database performance if it is frequently accessed.
</para>
<para>
[parent: 194e6ee74b02]