On 03.09.2013 16:22, Merlin Moncure wrote:
On Mon, Sep 2, 2013 at 10:32 PM, Bruce Momjian<br...@momjian.us>  wrote:
On Mon, Sep  2, 2013 at 10:14:03AM +0300, Heikki Linnakangas wrote:
diff --git a/src/backend/access/transam/xlog.c 
b/src/backend/access/transam/xlog.c
index 39c58d0..28e62ea 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -428,8 +428,14 @@ typedef struct XLogCtlInsert
       uint64          CurrBytePos;
       uint64          PrevBytePos;

-     /* insertion slots, see above for details */
-     XLogInsertSlotPadded *insertSlots;
+     /*
+      * Make sure the above heavily-contended spinlock and byte positions are
+      * on their own cache line. In particular, the RedoRecPtr and full page
+      * write variables below should be on a different cache line. They are
+      * read on every WAL insertion, but updated rarely, and we don't want
+      * those reads to steal the cache line containing Curr/PrevBytePos.
+      */
+     char            pad[128];

Do we adjust for cache line lengths anywhere else?  PGPROC?  Should it
be a global define?

+1 -- that is, I think it should be.

Ok, committed that way. No, we adjust for cache line lengths anywhere else. As Alvaro noted, LWLocks are padded, but that's just to keep them from crossing cache line boundaries, not to keep two lwlocks on separate cache lines.

Thanks!

- Heikki


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to