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(at)jepsen(dot)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.
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