Horton

Re: Potential G2-item cycles under serializable isolation

Kyle Kingsbury <aphyr@jepsen.io>

View thread View on postgr.es
From: Kyle Kingsbury <aphyr@jepsen.io>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-06-01T04:05:19Z
Lists: pgsql-bugs 
Oh! Gosh, yes, that DOES explain it. Somehow I had it in my head that both
RU and RC mapped to SI, and RR & Serializable mapped to SSI. That's the
case in YugabyteDB, but not here!

I'll also see about getting a version of these tests that doesn't involve
ON CONFLICT, in case that's relevant.

--Kyle

On Sun, May 31, 2020, 23:56 Peter Geoghegan <pg@bowt.ie> wrote:

> On Sun, May 31, 2020 at 8:37 PM Kyle Kingsbury <aphyr@jepsen.io> wrote:
> > This looks so weird that I assume I've *got* to be doing it wrong, but
> trawling
> > through the source code and pcap trace, I can't see where the mistake
> is. Maybe
> > I'll have fresher eyes in the morning. :)
>
> READ COMMITTED starts each command within a transaction with its own
> snapshot, much like Oracle:
>
> https://www.postgresql.org/docs/devel/transaction-iso.html
>
> There cannot be serialization errors with READ COMMITTED mode, and in
> general it is a lot more permissive. Probably to the point where it
> isn't sensible to test with Jepsen at all.
>
> It would make sense for you to test REPEATABLE READ isolation level
> separately, though. It implements snapshot isolation without the added
> overhead of the mechanisms that prevent (or are supposed to prevent)
> serialization anomalies.
>
> --
> Peter Geoghegan
>

Commits

  1. Doc: Add references for SI and SSI.

  2. Improve comments for [Heap]CheckForSerializableConflictOut().

  3. Avoid update conflict out serialization anomalies.

  4. Implement genuine serializable isolation level.