Horton

Re: SSI non-serializable UPDATE performance

Kevin Grittner <kevin.grittner@wicourts.gov>

View thread
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Dan Ports" <drkp@csail.mit.edu>, "Robert Haas" <robertmhaas@gmail.com>
Cc: "Simon Riggs" <simon@2ndQuadrant.com>, "pgsql-hackers" <pgsql-hackers@postgresql.org>
Date: 2011-04-28T16:29:47Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add fast paths for cases when no serializable transactions are running.

Robert Haas <robertmhaas@gmail.com> wrote:
> On Apr 28, 2011, at 9:55 AM, Dan Ports <drkp@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
 
-Kevin