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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <drkp(at)csail(dot)mit(dot)edu>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-24 09:18:37
Message-ID: 4DDB319D020000250003DBAD@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-05-24 10:40:40 Operator families vs. casts
Previous Message Noah Misch 2011-05-24 09:07:34 Re: Reducing overhead of frequent table locks