Re: SSI non-serializable UPDATE performance - Mailing list pgsql-hackers

From Robert Haas
Subject Re: SSI non-serializable UPDATE performance
Date
Msg-id 65170A0B-F4C9-433D-AC93-98943D83DCA3@gmail.com
Whole thread Raw
In response to Re: SSI non-serializable UPDATE performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI non-serializable UPDATE performance  (Dan Ports <drkp@csail.mit.edu>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: unknown conversion %m
Next
From: Andrew Dunstan
Date:
Subject: Re: XML with invalid chars