Lists: | pgsql-hackers |
---|
From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | <simon(at)2ndQuadrant(dot)com>,<markus(at)bluegap(dot)ch>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSI patch version 14 |
Date: | 2011-02-05 20:43:11 |
Message-ID: | 4D4D61FF020000250003A479@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
"Kevin Grittner" wrote:
> So now that I'm sure we actually do need code there, I'll add it.
In working on this I noticed the apparent need to move two calls to
PredicateLockTuple a little bit to keep them inside the buffer lock.
Without at least a share lock on the buffer, it seems that here is a
window where a read could miss the MVCC from a write and the write
could fail to see the predicate lock. Please see whether this seems
reasonable:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=7841a22648c3f4ae46f674d7cf4a7c2673cf9ed2
> And I'll add the new test to the isolation suite.
We don't need all permutations for this test, which is a good thing
since it has such a long setup time. Is there an easy way to just
run the one schedule of statements on three connections?
-Kevin
From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | heikki(dot)linnakangas(at)enterprisedb(dot)com, simon(at)2ndQuadrant(dot)com, markus(at)bluegap(dot)ch, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI patch version 14 |
Date: | 2011-02-06 19:08:37 |
Message-ID: | 1297019317.27157.157.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Sat, 2011-02-05 at 14:43 -0600, Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>
> > So now that I'm sure we actually do need code there, I'll add it.
>
> In working on this I noticed the apparent need to move two calls to
> PredicateLockTuple a little bit to keep them inside the buffer lock.
> Without at least a share lock on the buffer, it seems that here is a
> window where a read could miss the MVCC from a write and the write
> could fail to see the predicate lock. Please see whether this seems
> reasonable:
>
> http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=7841a22648c3f4ae46f674d7cf4a7c2673cf9ed2
What does PredicateLockTuple do that needs a share lock? Does a pin
suffice?
Regards,
Jeff Davis
From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | simon(at)2ndQuadrant(dot)com, markus(at)bluegap(dot)ch, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SSI patch version 14 |
Date: | 2011-02-07 11:10:10 |
Message-ID: | 4D4FD312.50008@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On 05.02.2011 21:43, Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>
>> So now that I'm sure we actually do need code there, I'll add it.
>
> In working on this I noticed the apparent need to move two calls to
> PredicateLockTuple a little bit to keep them inside the buffer lock.
> Without at least a share lock on the buffer, it seems that here is a
> window where a read could miss the MVCC from a write and the write
> could fail to see the predicate lock. Please see whether this seems
> reasonable:
>
> http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=7841a22648c3f4ae46f674d7cf4a7c2673cf9ed2
>
>> And I'll add the new test to the isolation suite.
>
> We don't need all permutations for this test, which is a good thing
> since it has such a long setup time. Is there an easy way to just
> run the one schedule of statements on three connections?
Not at the moment, but we can add that..
I added the capability to specify exact permutations like:
permutation "rwx1" "rwx2" "c1" "c2"
See my git repository at
git://git.postgresql.org/git/users/heikki/postgres.git, branch
"serializable". I also added a short README to explain what the
isolation test suite is all about, as well as separate "make check" and
"make installcheck" targets.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com