From 0fad355beca9f73687c0b27647ea570ce10c7ae3 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Wed, 4 Jan 2017 12:03:40 -0500
Subject: [PATCH] Update obsolete comments in lwlock.h.

The typical size of an LWLock is now 16 bytes even on 64-bit platforms,
and the size of slock_t is now irrelevant.  But pg_atomic_uint32 can
(perhaps surprisingly) still be larger than 4 bytes, so there's still
some marginal point to allowing LWLOCK_MINIMAL_SIZE == 64.

Commit 008608b9d51061b1f598c197477b3dc7be9c4a64 made the changes
that led to the need for these updates.
---
 src/include/storage/lwlock.h | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/src/include/storage/lwlock.h b/src/include/storage/lwlock.h
index 133ed6dc834..8bd93c3b819 100644
--- a/src/include/storage/lwlock.h
+++ b/src/include/storage/lwlock.h
@@ -58,16 +58,17 @@ typedef struct LWLock
  * LWLockPadded can be used for cases where we want each lock to be an entire
  * cache line.
  *
- * On 32-bit platforms, an LWLockMinimallyPadded might actually contain more
- * than the absolute minimum amount of padding required to keep a lock from
- * crossing a cache line boundary, because an unpadded LWLock might fit into
- * 16 bytes.  We ignore that possibility when determining the minimal amount
- * of padding.  Older releases had larger LWLocks, so 32 really was the
- * minimum, and packing them in tighter might hurt performance.
+ * An LWLockMinimallyPadded might contain more than the absolute minimum amount
+ * of padding required to keep a lock from crossing a cache line boundary,
+ * because an unpadded LWLock will normally fit into 16 bytes.  We ignore that
+ * possibility when determining the minimal amount of padding.  Older releases
+ * had larger LWLocks, so 32 really was the minimum, and packing them in
+ * tighter might hurt performance.
  *
  * LWLOCK_MINIMAL_SIZE should be 32 on basically all common platforms, but
- * because slock_t is more than 2 bytes on some obscure platforms, we allow
- * for the possibility that it might be 64.
+ * because pg_atomic_uint32 is more than 4 bytes on some obscure platforms, we
+ * allow for the possibility that it might be 64.  Even on those platforms,
+ * we probably won't exceed 32 bytes unless LOCK_DEBUG is defined.
  */
 #define LWLOCK_PADDED_SIZE	PG_CACHE_LINE_SIZE
 #define LWLOCK_MINIMAL_SIZE (sizeof(LWLock) <= 32 ? 32 : 64)
-- 
GitLab