Horton

Re: SSI non-serializable UPDATE performance

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Dan Ports <drkp@csail.mit.edu>, Simon Riggs <simon@2ndQuadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-04-28T16:45:54Z
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.

On Apr 28, 2011, at 6:29 PM, "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
> 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

Yeah, I think Dan's notes about memory ordering would be good to include.

...Robert