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

From Kevin Grittner
Subject Re: SSI predicate locking on heap -- tuple or row?
Date
Msg-id 4DDB319D020000250003DBAD@gw.wicourts.gov
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?  (Dan Ports <drkp@csail.mit.edu>)
List pgsql-hackers
"Kevin Grittner"  wrote:
> Dan Ports  wrote:
>> Does that make sense to you?
> 
> Makes sense to me. Like the proof I offered, you have shown that
> there is no cycle which can develop with the locks copied which
> isn't there anyway if we don't copy the locks.
I woke up with the nagging thought that while the above is completely
accurate, it deserves some slight elaboration. 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. 
That's a good thing.  In addition to the benefits mentioned in prior
posts, there will be a reduction in the rate of rollbacks (in
particular corner cases) from what people see in beta1 without a loss
of correctness.
-Kevin


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Reducing overhead of frequent table locks
Next
From: Noah Misch
Date:
Subject: Operator families vs. casts