[Jepsen][YSQL] A lot of transaction consistency violations in Jepsen Elle while using REPEATABLE READ transactions.

[qvad]

Jira Link: DB-2786

Description

Added REPEATABLE READ Elle test in Jepsen. Since we threat REPEATABLE READ transactions as SNAPSHOT, following configuration used for test.

(defn workload-si
  [opts]
  (-> (append/test {:key-count          32
                    :max-txn-length     4
                    :max-writes-per-key 1024
                    :anomalies          [:internal :G-nonadjacent :G1 :G-SI]
                    :consistency-models [:snapshot-isolation]
                    :additional-graphs  [elle/realtime-graph]})))

Current test implementation is the same for all isolation levels, but only REPEATABLE READ case failed PR Draft - https://github.com/yugabyte/jepsen/pull/69/files Common code (only isolation level changed and checker params)

    (let [txn (:value op)
           use-txn? (< 1 (count txn))
           txn' (if use-txn?
                  (j/with-db-transaction [c c {:isolation isolation}]
                                         (mapv (partial mop! c test) txn))
                  (mapv (partial mop! c test) txn))]

There is a lot consistency violations in analysis result. Serialisable and read committed test are fine and doesn't fail so easily.

:not #{:read-atomic :read-uncommitted},
            :also-not #{:ROLA
                        :causal-cerone
                        :consistent-view
                        :cursor-stability
                        :forward-consistent-view
                        :monotonic-atomic-view
                        :monotonic-snapshot-read
                        :monotonic-view
                        :parallel-snapshot-isolation
                        :prefix
                        :read-committed
                        :repeatable-read
                        :serializable
                        :snapshot-isolation
                        :strict-serializable
                        :strong-session-serializable
                        :strong-session-snapshot-isolation
                        :strong-snapshot-isolation
                        :update-serializable}

20220217T170008.000Z.zip

Here is some examples:

1. Dirty write

We append In single transaction 953 and 954 values into key 54, while in other transaction we read only 954

G0 #0
Let:
  T1 = {:type :ok, :f :txn, :value [[:append 54 805] [:append 54 806] [:r 54 [... 828 804 954 805 806]]], :time 264394623833, :process 894, :op-timing ["2022-02-17_17:04:50.339" "2022-02-17_17:04:58.664"], :index 46494}
  T2 = {:type :ok, :f :txn, :value [[:append 54 953] [:append 54 954]], :time 263078557704, :process 585, :op-timing ["2022-02-17_17:04:52.684" "2022-02-17_17:04:57.348"], :index 46242}

2. Read skew

   
   G-single #3
   Let:
   T1 = {:type :ok, :f :txn, :value [[:append 47 753] [:r 47 [...  1023 987 1024 923 605]]], :time 194520931638, :process 504, :op-timing ["2022-02-17_17:03:43.205" "2022-02-17_17:03:48.791"], :index 32776}
   T2 = {:type :ok, :f :txn, :value [[:append 47 604] [:r 47 [.... 987 1024 923]] [:append 47 605] ... ], :time 193951238563, :process 767, :op-timing ["2022-02-17_17:03:40.461" "2022-02-17_17:03:48.210"], :index 32686}

Then:

• T1 < T2, because T1 did not observe T2's append of 604 to 47.
• However, T2 < T1, because T1 appended 753 after T2 appended 605 to 47: a contradiction!

  3. G-nonadjacent
  Very tricky inconsistency since the reason may be hidden from report. We saw it previously in append test and there was Read You Writes violation, here we have another one which is looks like more related to dirty writes.

  G-nonadjacent #3 Let: T1 = {:type :ok, :f :txn, :value [[:append 63 682] [:r 62 [...] [:append 61 336] [:append 61 337]], :time 321916346345, :process 1216, :op-timing ["2022-02-17_17:05:53.600" "2022-02-17_17:05:56.186"], :index 57642} T2 = {:type :ok, :f :txn, :value [[:append 59 900] [:r 63 [1... 756 706 682]]], :time 322886762699, :process 1359, :op-timing ["2022-02-17_17:05:52.532" "2022-02-17_17:05:57.157"], :index 57646} T3 = {:type :ok, :f :txn, :value [[:append 63 667] [:append 63 668]], :time 322650336679, :process 1074, :op-timing ["2022-02-17_17:05:53.344" "2022-02-17_17:05:56.920"], :index 57645} T4 = {:type :ok, :f :txn, :value [[:append 63 683] [:r 61 [.... 353 337]]], :time 323927267411, :process 1124, :op-timing ["2022-02-17_17:05:53.600" "2022-02-17_17:05:58.197"], :index 57648}

Then:

• T1 < T2, because T2 observed T1's append of 682 to key 63.
• T2 < T3, because T2 did not observe T3's append of 668 to 63.
• T3 < T4, because T4 appended 683 after T3 appended 668 to 63.
• However, T4 < T1, because T4 did not observe T1's append of 336 to 61: a contradiction!

[m-iancu]

^cc @spolitov @pkj415 @robertsami

[qvad]

According to bisect testing this commit is related to consistency issue