Re: Potential G2-item cycles under serializable isolation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Kyle Kingsbury <aphyr(at)jepsen(dot)io>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Potential G2-item cycles under serializable isolation
Date: 2020-06-06 22:24:35
Message-ID: CAH2-Wz=9szcV1CQk4ZTj2GOKdjzf_DAAbfXdssKJnxpdX3pL2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Jun 6, 2020 at 5:49 AM Kyle Kingsbury <aphyr(at)jepsen(dot)io> wrote:
> Here's a quick runthrough of G2-item #0:
>
> Let:
> T1 = {:type :ok, :f :txn, :value [[:append 1468 3] [:r 1469 nil] [:append
> 1439 2]], :time 22408795244, :process 49, :index 10392}
> T2 = {:type :ok, :f :txn, :value [[:append 1469 1] [:append 1456 2] [:r 1468
> nil]], :time 22565885165, :process 45, :index 10464}
>
> Then:
> - T1 < T2, because T1 observed the initial (nil) state of 1469, which T2
> created by appending 1.
> - However, T2 < T1, because T2 observed the initial (nil) state of 1468,
> which T1 created by appending 3: a contradiction!
>
> Classic G2: two rw-edges, where each transaction failed to observe the other's
> write.

Here is a restatement of the same anomaly with RR event number
annotations, to make it easy for other people to match up each
observation/modification to a query from the log file I made available
yesterday:

G2-item #0
Let:
T1 = {:type :ok, :f :txn, :value [[:append 1468 3] [:r 1469 nil]
[:append 1439 2]], :time 22408795244, :process 49, :index 10392}
T2 = {:type :ok, :f :txn, :value [[:append 1469 1] [:append 1456 2]
[:r 1468 nil]], :time 22565885165, :process 45, :index 10464}

Then:
- T1 < T2, because T1 observed the initial (nil) state of 1469 (at
RR 582419), which T2 created by appending 1 (at RR 581548).
- However, T2 < T1, because T2 observed the initial (nil) state of
1468 (at RR 582018), which T1 created by appending 3 (at RR 581374):
-- a contradiction!

Possibly silly question: Doesn't "observing the initial (nil) state"
mean that no rows were returned by a SELECT statement? For example,
doesn't that just mean that the following SELECT statement returns no
rows?:

[rr 316514 582419]
1591388175.902-316514-13/403-1680806-SELECT-5edaa7f9.4d462-jepsen
process 49 LOG: execute <unnamed>: select (val) from txn2 where sk =
$1
1591388175.902-316514-13/403-1680806-SELECT-5edaa7f9.4d462-jepsen
process 49 DETAIL: parameters: $1 = '1469'

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2020-06-07 06:17:18 Re: BUG #16483: pg_ctl -D $PREFIX/var/lib/postgresql start
Previous Message PG Bug reporting form 2020-06-06 19:37:06 BUG #16483: pg_ctl -D $PREFIX/var/lib/postgresql start