On Fri, Apr 29, 2011 at 3:23 AM, Dan Ports wrote:
> On Thu, Apr 28, 2011 at 06:45:54PM +0200, Robert Haas wrote:
>> Yeah, I think Dan's notes about memory ordering would be good to include.
>
> I left it out initially because I didn't want to make things more
> confusing. As far as memory ordering
On Thu, Apr 28, 2011 at 06:45:54PM +0200, Robert Haas wrote:
> Yeah, I think Dan's notes about memory ordering would be good to include.
I left it out initially because I didn't want to make things more
confusing. As far as memory ordering is concerned, this is the same
story as anything else that
On Apr 28, 2011, at 6:29 PM, "Kevin Grittner"
wrote:
> Robert Haas wrote:
>> On Apr 28, 2011, at 9:55 AM, Dan Ports 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
Robert Haas wrote:
> On Apr 28, 2011, at 9:55 AM, Dan Ports 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 t
On Apr 28, 2011, at 9:55 AM, Dan Ports wrote:
> On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
>>> We added a quick return which didn't need to check any locks at the
>>> front of this routine which is taken if there are no active
>>> serializable transactions on the cluster at the m
On Thu, Apr 28, 2011 at 08:43:30AM +0100, Simon Riggs wrote:
> > We added a quick return which didn't need to check any locks at the
> > front of this routine which is taken if there are no active
> > serializable transactions on the cluster at the moment of update.
>
> Surprised to hear nobody me
On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
wrote:
> (1) If a tuple which is predicate locked, or sits on a predicate-
> locked page, is updated, the predicate lock is duplicated for the
> new tuple. We have found patterns of updates involving four or more
> transactions where a non-serializ
On Wed, Apr 27, 2011 at 7:15 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> Reading the code, IIUC, we check for RW conflicts after each write
>> but only if the writer is running a serializable transaction.
>
> Correct as far as that statement goes.
Thanks.
I'm surprised by that though, i
Simon Riggs wrote:
> Reading the code, IIUC, we check for RW conflicts after each write
> but only if the writer is running a serializable transaction.
Correct as far as that statement goes. There are cases where
predicate lock maintenance is needed when dealing with locked
resources; see bel
On Wed, Apr 27, 2011 at 06:26:52PM +0100, Simon Riggs wrote:
> Reading the code, IIUC, we check for RW conflicts after each write but
> only if the writer is running a serializable transaction.
>
> Am I correct in thinking that there is zero impact of SSI if nobody is
> running a serializable tran
On Mon, Apr 25, 2011 at 4:33 AM, Dan Ports wrote:
> On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
>> Even though this didn't show any difference in Dan's performance
>> tests, it seems like reasonable insurance against creating a new
>> bottleneck in very high concurrency situati
On Sun, Apr 24, 2011 at 11:33 PM, Dan Ports wrote:
> On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
>> Even though this didn't show any difference in Dan's performance
>> tests, it seems like reasonable insurance against creating a new
>> bottleneck in very high concurrency situat
On Sat, Apr 23, 2011 at 08:54:31AM -0500, Kevin Grittner wrote:
> Even though this didn't show any difference in Dan's performance
> tests, it seems like reasonable insurance against creating a new
> bottleneck in very high concurrency situations.
>
> Dan, do you have a patch for this, or should
13 matches
Mail list logo
