[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-hackers
Subject:    Re: [HACKERS] SSI non-serializable UPDATE performance
From:       Dan Ports <drkp () csail ! mit ! edu>
Date:       2011-04-29 7:23:56
Message-ID: 20110429072356.GF1432 () csail ! mit ! edu
[Download RAW message or body]

On Thu, Apr 28, 2011 at 06:45:54PM +0200, Robert Haas wrote:
> Yeah, I think Dan's notes about memory ordering would be good to include.

I left it out initially because I didn't want to make things more
confusing. As far as memory ordering is concerned, this is the same
story as anything else that uses lwlocks: the spinlock memory barrier
prevents memory accesses from being reordered before the lock is
acquired. The only unusual thing here is that the lock in question
isn't the one that protects the variable we're reading.

But I'm OK with adding a comment if you think it helps. Patch attached.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/

["ssi-memory-ordering-comment.patch" (text/x-diff)]

diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index fe0e458..694e87d 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -2298,6 +2298,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;


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


[prev in list] [next in list] [prev in thread] [next in thread]