From ea41b8c822df5a2e4862c76d72937df9b62f1a99 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 24 Jun 2011 16:06:57 -0400 Subject: [PATCH] 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 24d7d98722..d2da4ac176 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -7078,13 +7078,18 @@ - When the pg_locks 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 pg_locks 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. -- 2.40.0