Re: Serializable Snapshot Isolation

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Serializable Snapshot Isolation
Дата
Msg-id AANLkTimv=90KrnreD3ki+=HanXeU_eDeruKTitwDK_BS@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Serializable Snapshot Isolation  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Serializable Snapshot Isolation
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Stalled post to pgsql-committers