From 5943d4016854fe5064687cf7487487087ee61425 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 28 Nov 2011 13:51:58 -0500 Subject: [PATCH] Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page. --- doc/src/sgml/catalogs.sgml | 73 ++++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 34 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index f1dcf8ab1a..8156c35916 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -7100,6 +7100,8 @@ in the same way as in pg_description or pg_depend). Also, the right to extend a relation is represented as a separate lockable object. + Also, advisory locks can be taken on numbers that have + user-defined meanings. @@ -7202,9 +7204,7 @@ any OID column OID of the lock target within its system catalog, or null if the - target is not a general database object. - For advisory locks it is used to distinguish the two key - spaces (1 for an int8 key, 2 for two int4 keys). + target is not a general database object @@ -7233,7 +7233,7 @@ Process ID of the server process holding or awaiting this - lock. Null if the lock is held by a prepared transaction. + lock, or null if the lock is held by a prepared transaction @@ -7253,7 +7253,8 @@ fastpath boolean - True if lock was taken via fast path, false if taken via main lock table + True if lock was taken via fast path, false if taken via main + lock table @@ -7292,7 +7293,8 @@ Advisory locks can be acquired on keys consisting of either a single - bigint value or two integer values. A bigint key is displayed with its + bigint value or two integer values. + A bigint key is displayed with its high-order half in the classid column, its low-order half in the objid column, and objsubid equal to 1. Integer keys are displayed with the first key in the @@ -7302,34 +7304,6 @@ so the database column is meaningful for an advisory lock. - - The pg_locks view displays data from both the - regular lock manager and the predicate lock manager, which are - separate systems. This data is not guaranteed to be entirely consistent. - Data on fast-path locks (with fastpath = true) - is gathered from each backend one at a time, without freezing the state of - the entire lock manager, so it is possible for locks to be taken and - released as information is gathered. Note, however, that these locks are - known not to conflict with any other lock currently in place. After - all backends have been queried for fast-path locks, the remainder of the - lock manager is locked as a unit, and a consistent snapshot of all - remaining locks is dumped as an atomic action. Once the lock manager has - been unlocked, the predicate lock manager is similarly locked and all - predicate locks are dumped as an atomic action. Thus, with the exception - of fast-path locks, each lock manager will deliver 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. - - - - Locking the lock manger and/or predicate lock manager could have some - impact on database performance if this view is very frequently accessed. - The locks are held only for the minimum amount of time necessary to - obtain data from the lock manager, but this does not completely eliminate - the possibility of a performance impact. - - pg_locks provides a global view of all locks in the database cluster, not only those relevant to the current database. @@ -7354,6 +7328,37 @@ but it continues to hold the locks it acquired while running.) + + The pg_locks view displays data from both the + regular lock manager and the predicate lock manager, which are + separate systems; in addition, the regular lock manager subdivides its + locks into regular and fast-path locks. + This data is not guaranteed to be entirely consistent. + When the view is queried, + data on fast-path locks (with fastpath = true) + is gathered from each backend one at a time, without freezing the state of + the entire lock manager, so it is possible for locks to be taken or + released while information is gathered. Note, however, that these locks are + known not to conflict with any other lock currently in place. After + all backends have been queried for fast-path locks, the remainder of the + regular lock manager is locked as a unit, and a consistent snapshot of all + remaining locks is collected as an atomic action. After unlocking the + regular lock manager, the predicate lock manager is similarly locked and all + predicate locks are collected as an atomic action. Thus, with the exception + of fast-path locks, each lock manager will deliver 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. + + + + Locking the regular and/or predicate lock manager could have some + impact on database performance if this view is very frequently accessed. + The locks are held only for the minimum amount of time necessary to + obtain data from the lock managers, but this does not completely eliminate + the possibility of a performance impact. + +