Re: SSI patch version 14

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