Horton

Re: Potential G2-item cycles under serializable isolation

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Kyle Kingsbury <aphyr@jepsen.io>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-06-04T01:33:45Z
Lists: pgsql-bugs 
On Wed, Jun 3, 2020 at 4:26 PM Kyle Kingsbury <aphyr@jepsen.io> wrote:
> Oh this is interesting! I can say that I'm running on a 24-way Xeon with 128gb of ram, so running out of system memory doesn't immediately seem like a bottleneck--I'd suspect my config runs slower by dint of disks (older SSD), fs settings, or maybe postgres tuning (this is with the stock Debian config files).

I can now get it to run fairly consistently, now that I know to
consistently truncate all three tables between runs. It doesn't always
fail, but it fails often enough. And it doesn't seem to matter that my
local Postgres is so much faster, or has fewer failures. For example,
I now see the following failure on Postgres 13:

INFO [2020-06-03 18:26:50,706] jepsen test runner - jepsen.core {:perf
 {:latency-graph {:valid? true},
  :rate-graph {:valid? true},
  :valid? true},
 :clock {:valid? true},
 :stats
 {:valid? true,
  :count 30049,
  :ok-count 26792,
  :fail-count 3200,
  :info-count 57,
  :by-f
  {:txn
   {:valid? true,
    :count 30049,
    :ok-count 26792,
    :fail-count 3200,
    :info-count 57}}},
 :exceptions {:valid? true},
 :workload
 *** SNIP ***

Kyle: Could you figure out a way of setting "prepareThreshold=0" in
JDBC (i.e. disable prepared statements), please? That would make it a
bit easier to debug.

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