Re: Serializable Snapshot Isolation - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Serializable Snapshot Isolation
Date
Msg-id AANLkTimv=90KrnreD3ki+=HanXeU_eDeruKTitwDK_BS@mail.gmail.com
Whole thread Raw
In response to Re: Serializable Snapshot Isolation  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Sat, Sep 25, 2010 at 4:24 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> OK, to get back to the question -- pg_dump's transaction (T0) could
> see an inconsistent version of the database if one transaction (TN)
> writes to a table, another transaction (T1) overlaps TN and can't
> read something written by TN because they are concurrent, TN commits
> before T0 acquires its snapshot, T1 writes to a table, T0 starts
> before T1 commits, and T0 can't read something which T1 wrote (which
> is sort of a given for a database dump and overlapping transactions).

Can I collapse this into a single list of events (apologies, this
isn't going to line up, I'm writing it in a proportional font :( )

TN starts                 T1 starts
TN writes                 T1 reads
TN commits                                    T0 starts (pg_dump)                 T1 writes
      T0 reads (pg_dump)                 T1 commits
 

So T1 must have happened before TN because it wrote something based on
data as it was before TN modified it. But T0 can see TN but not T1 so
there's no complete ordering between the three transactions that makes
them all make sense.

The thing is that the database state is reasonable, the database state
is after it would be if the ordering were T1,TN with T0 happening any
time. And the backup state is reasonable, it's as if it occurred after
TN and before T1. They just don't agree.

-- 
greg


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Serializable Snapshot Isolation
Next
From: Peter Eisentraut
Date:
Subject: Stalled post to pgsql-committers