Re: SSI predicate locking on heap -- tuple or row?

From: Dan Ports <drkp(at)csail(dot)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-25 00:25:54
Message-ID: 20110525002554.GC95874@csail.mit.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 24, 2011 at 04:18:37AM -0500, Kevin Grittner wrote:
> These proofs show that
> there is no legitimate cycle which could cause an anomaly which the
> move from row-based to tuple-based logic will miss. They don't prove
> that the change will generate all the same serialization failures;
> and in fact, some false positives are eliminated by the change.

Yes, that's correct. That's related to the part in the proof where I
claimed T3 couldn't have a conflict out *to some transaction T0 that
precedes T1*.

I originally tried to show that T3 couldn't have any conflicts out that
T2 didn't have, which would mean we got the same set of serialization
failures, but that's not true. In fact, it's not too hard to come up
with an example where there would be a serialization failure with the
row version links, but not without. However, because the rw-conflict
can't be pointing to a transaction that precedes T1 in the serial
order, it won't create a cycle. In other words, there are serialization
failures that won't happen anymore, but they were false positives.

Dan

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-05-25 01:47:26 Re: 9.2 schedule
Previous Message Jaime Casanova 2011-05-24 23:26:22 Re: adding a new column in IDENTIFY_SYSTEM