Add comment about memory reordering to PredicateLockTupleRowVersionLink.

Dan Ports, per head-scratching from Simon Riggs and myself.

diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index 48ff9cc151d89435bbeeef25ec8e5ba9b58c344a..3b3158efe55d24cb86d6e4d04d64dfc61647842f 100644 (file)
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -2283,6 +2283,9 @@ PredicateLockTupleRowVersionLink(const Relation relation,
     * locks. Even if a serializable transaction starts concurrently,
     * we know it can't take any SIREAD locks on the modified tuple
     * because the caller is holding the associated buffer page lock.
+    * Memory reordering isn't an issue; the memory barrier in the
+    * LWLock acquisition guarantees that this read occurs while the
+    * buffer page lock is held.
     */
    if (!TransactionIdIsValid(PredXact->SxactGlobalXmin))
        return;