Further work on comments about SerializablePredicateLockListLock.

diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index f47df90b6d6e831c15f4f4efd403cbbcf6b40500..8f4bdb27ee8584b25cc33332f6a721ad0cd03148 100644 (file)
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -78,19 +78,31 @@
  *         may yet matter because they overlap still-active transactions.
  *
  * SerializablePredicateLockListLock
- *     - Protects the linked list of locks held by a transaction.
+ *     - Protects the linked list of locks held by a transaction.  Note
+ *         that the locks themselves are also covered by the partition
+ *         locks of their respective lock targets; this lock only affects
+ *         the linked list connecting the locks related to a transaction.
  *     - All transactions share this single lock (with no partitioning).
- *     - Special handling: There is never a need for a process other than
- *         the one running a transaction to walk the list of locks held
- *         by that transaction.  It is relatively infrequent that another
- *         process needs to modify the list, but it does happen for such
- *         things as index page splits and vacuuming of locked pages.
- *         Cleaning up the list is *not* done on a retail basis, so no
- *         lock is required there.  When a process is accessing its
- *         active transaction's list, it always uses a shared lock,
- *         regardless of whether it is walking or maintaining the list.
- *         If a process needs to alter the list of some other process,
- *         it must acquire an exclusive lock.
+ *     - There is never a need for a process other than the one running
+ *         a transaction to walk the list of locks held by that
+ *         transaction.
+ *     - It is relatively infrequent that another process needs to
+ *         modify the list for a transaction, but it does happen for such
+ *         things as index page splits for pages with predicate locks and
+ *         freeing of predicate locked pages by a vacuum process.  When
+ *         removing a lock in such cases, the lock itself contains the
+ *         pointers needed to remove it from the list.  When adding a
+ *         lock in such cases, the lock can be added using the anchor in
+ *         the transaction structure.
+ *     - Cleaning up the list for a terminated transaction is *not* done
+ *         on a retail basis, so no lock is required there.
+ *     - Due to the above, a process accessing its active transaction's
+ *         list can always uses a shared lock, regardless of whether it
+ *         is walking or maintaining the list.  This improves concurrency
+ *         for the common access patterns.
+ *     - A process which needs to alter the list of a transaction other
+ *         than its own active transaction must acquire an exclusive
+ *         lock.
  *
  * FirstPredicateLockMgrLock based partition locks
  *     - The same lock protects a target, all locks on that target, and