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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Dan Ports" <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-23 21:06:23
Message-ID: 4DDA85FF020000250003DB58@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dan Ports <drkp(at)csail(dot)mit(dot)edu> wrote:

> 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.

OK, I misread your post -- you are looking at T1 as the pivot, and
that test *is* the problem. When T1 becomes the pivot the reader
(T4) is committed, but it committed *after* T2. I can submit a
patch for that this evening, after testing to confirm that if finds
the T1 pivot, unless you want to get it.

Sorry for the misunderstanding. I'm sneaking peeks at this during
compiles of other stuff....

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2011-05-23 21:14:53 Re: Identifying no-op length coercions
Previous Message Tom Lane 2011-05-23 20:41:06 Re: Identifying no-op length coercions