Re: SSI non-serializable UPDATE performance

On Apr 28, 2011, at 6:29 PM, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Apr 28, 2011, at 9:55 AM, Dan Ports <drkp(at)csail(dot)mit(dot)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