On Apr 28, 2011, at 6:29 PM, "Kevin Grittner" <kevin.gritt...@wicourts.gov> wrote: > Robert Haas <robertmh...@gmail.com> wrote: >> On Apr 28, 2011, at 9:55 AM, Dan Ports <d...@csail.mit.edu> wrote: > >>> The memory barrier when acquiring the buffer page lwlock acts as >>> the synchronization point we need. When we see that no >>> serializable transactions are running, that could have been >>> reordered, but that read still had to come after the lock was >>> taken. That's all we need: even if another backend starts a >>> serializable transaction after that, we know it can't take any >>> SIREAD locks on the same target while we're holding the buffer >>> page lock. >> >> Sounds like that might be worth a comment. > > There were comments; after reading that post, do you think they need > to be expanded or reworded?: > > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=02e6a115cc6149551527a45545fd1ef8d37e6aa0
Yeah, I think Dan's notes about memory ordering would be good to include. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
