Re: SSI predicate locking on heap -- tuple or row? - Mailing list pgsql-hackers

From Dan Ports
Subject Re: SSI predicate locking on heap -- tuple or row?
Date
Msg-id 20110523183233.GF85637@csail.mit.edu
Whole thread Raw
In response to SSI predicate locking on heap -- tuple or row?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI predicate locking on heap -- tuple or row?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SSI predicate locking on heap -- tuple or row?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Sat, May 21, 2011 at 03:09:12PM -0500, Kevin Grittner wrote:
> I went back to the example which persuaded me and took another look.  On
> review I see that this didn't prove the point because there was a
> dangerous structure with T1 as a pivot which should have caused SSI to
> break the cycle.  Since it didn't, either I got careless in my testing
> methodology (which I will recheck when I get back to Wisconsin) or there
> was a bug -- but either way, this example can't prove that the predicate
> locks need to follow the row to new versions.

I'm still working through the more general question, but I wanted to
see what was going on with this example. It appears there's a bug,
because this doesn't cause a rollback without the version linking.

Specifically, the problem is a missing check in
OnConflict_CheckForSerializationFailure. We check whether the conflict
has caused the writer to become a pivot, but only if neither the reader
or writer is committed. Why is that last condition there? In this case,
the reader (T4) has committed but the writer (T1) hasn't.

It would be worth making sure there aren't any other cases we're
missing here, although I don't see any right now.

Dan

-- 
Dan R. K. Ports              MIT CSAIL                http://drkp.net/


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sepgsql: fix relkind handling on foreign tables
Next
From: Noah Misch
Date:
Subject: Re: Identifying no-op length coercions