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