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. + +