Re: SSI patch version 8 - Mailing list pgsql-hackers

From Anssi Kääriäinen
Subject Re: SSI patch version 8
Date
Msg-id 4D2C4671.9070906@thl.fi
Whole thread Raw
In response to SSI patch version 8  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI patch version 8  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
SSI patch version 10  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SSI patch version 8  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On 01/10/2011 06:03 PM, Kevin Grittner wrote:
> Due to popular request (Hey, David's popular, right?), I'm posting a
> patch for Serializable Snapshot Isolation (SSI), although I don't
> yet have everything in it that I was planning on submitting before
> the CF.  I will probably be submitting another version before the
> deadline with the following, but there should be plenty here for
> people to test and benchmark.  We're done with the major refactoring
> needed to address concerns raised in earlier reviews, and I don't
> expect the remaining work to destabilize what's there or to have a
> significant impact on performance.
I think I found a problem. This is using SSI v8. The table definition:

create table test_t (id integer, val1 text, val2 integer);

create index test_idx on test_t(id) where val2 = 1;

The data:

insert into test_t (select generate_series(0, 10000), 'a', 2);
insert into test_t (select generate_series(0, 10), 'a', 1);

The transactions:
T1:
hot2=> begin transaction isolation level serializable;
BEGIN
hot2=> select * from test_t where val2 = 1; id | val1 | val2
----+------+------  0 | a    |    1  1 | a    |    1  2 | a    |    1  3 | a    |    1  4 | a    |    1  5 | a    |
1 6 | a    |    1  7 | a    |    1  8 | a    |    1  9 | a    |    1 10 | a    |    1
 
(11 rows)

hot2=> update test_t set val2 = 2 where val2 = 1 and id = 10;
UPDATE 1
-- The concurrent transaction:
T2:
hot2=> begin transaction isolation level serializable;
BEGIN
hot2=> select * from test_t where val2 = 1; id | val1 | val2
----+------+------  0 | a    |    1  1 | a    |    1  2 | a    |    1  3 | a    |    1  4 | a    |    1  5 | a    |
1 6 | a    |    1  7 | a    |    1  8 | a    |    1  9 | a    |    1 10 | a    |    1
 
(11 rows)

hot2=> update test_t set val2 = 2 where val2 = 1 and id = 9;
UPDATE 1
hot2=> commit;
COMMIT
-- Now, t1 can commit, too. Even though there is a serialization anomaly
T1:
hot2=> commit;
COMMIT

If the test_idx is changed:
(outside any transaction...)
hot2=> drop index test_idx;
DROP INDEX
hot2=> create index test_idx on test_t(id, val2);
CREATE INDEX


T1:
hot2=> begin transaction isolation level serializable;
BEGIN
hot2=> select * from test_t where val2 = 1; id | val1 | val2
----+------+------  0 | a    |    1  1 | a    |    1  2 | a    |    1  3 | a    |    1  4 | a    |    1  5 | a    |
1 6 | a    |    1  7 | a    |    1  8 | a    |    1
 
(9 rows)

hot2=> update test_t set val2 = 2 where val2 = 1 and id = 8;
UPDATE 1

T2:
hot2=> select * from test_t where val2 = 1; id | val1 | val2
----+------+------  0 | a    |    1  1 | a    |    1  2 | a    |    1  3 | a    |    1  4 | a    |    1  5 | a    |
1 6 | a    |    1  7 | a    |    1  8 | a    |    1
 
(9 rows)

hot2=> update test_t set val2 = 2 where val2 = 1 and id = 7;
UPDATE 1
hot2=> commit;
ERROR:  could not serialize access due to read/write dependencies among 
transactions
HINT:  The transaction might succeed if retried.
T1:
hot2=> commit;
COMMIT

So, something seems to be broken when using partial indexes.
 - Anssi



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ALTER TYPE 0: Introduction; test cases
Next
From: Simon Riggs
Date:
Subject: Re: ALTER TYPE 0: Introduction; test cases