Re: In-place updates and serializable transactions

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: In-place updates and serializable transactions
Дата
Msg-id CACjxUsM+FQebmUnXBYYQEGMjeN=10qV6Dy_Do4pC3ijsGMuB6g@mail.gmail.com
обсуждение исходный текст
Ответ на In-place updates and serializable transactions  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Список pgsql-hackers
On Tue, Nov 13, 2018 at 10:45 PM Kuntal Ghosh
<kuntalghosh.2007@gmail.com> wrote:

> Currently, we're working on the serializable implementations for
> zheap.

Great!

> If transaction T1 reads a row version (thus acquiring a predicate lock
> on it) and a second transaction T2 updates that row version (thus
> creating a rw-conflict graph edge from T1 to T2), must a third
> transaction T3 which re-updates the new version of the row also have a
> rw-conflict in from T1 to prevent anomalies?  In other words,  does it
> matter whether we recognize the edge T1 --rw--> T3?

No.  Keep in mind that extensive study has shown that snapshot
isolation can only be non-serializable if there is a cycle in the
apparent order of execution and that this can only occur if there is a
"dangerous structure" of two adjacent read-write antidependencies
(a/k/a read-write dependencies, a/k/a rw-conflicts) *AND* the
transaction you identify as T3 in that structure *IS THE FIRST
TRANSACTION IN THE CYCLE TO COMMIT*.  Looking at the implied T1/T3
relationship and looking for a T4 to complete the structure is not
necessary, because there are proofs that three *ADJACENT* transactions
are necessary for a serialization anomaly to be seen.

-- 
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Speeding up INSERTs and UPDATEs to partitioned tables
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Refactoring the checkpointer's fsync request queue