From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Dan Ports <drkp(at)csail(dot)mit(dot)edu>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSI non-serializable UPDATE performance |
Date: | 2011-04-28 16:45:54 |
Message-ID: | 65170A0B-F4C9-433D-AC93-98943D83DCA3@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-04-28 17:51:23 | Re: XML with invalid chars |
Previous Message | Tom Lane | 2011-04-28 16:41:08 | Re: unknown conversion %m |