Re: Potential G2-item cycles under serializable isolation

On 6/3/20 9:33 PM, Peter Geoghegan wrote:
> 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
memorydoesn'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.
The test will do that automatically for you now. :)
>   It doesn't always
> fail, but it fails often enough.

Hey, that's good!

>   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 ***
Aw shucks, you left out the good part! I'm guessing the workload returned 
{:valid? false} here?

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

Try out 21ae84ed: I added a --prepare-threshold option for you. :)

--Kyle