Re: Inconsistent behavior in serializable snapshot

Поиск
Список
Период
Сортировка
От Kuntal Ghosh
Тема Re: Inconsistent behavior in serializable snapshot
Дата
Msg-id CAGz5QC+E_o=9Kx4+syVaSt4afMopTTjNJm_Z-oVEfagk0mt_Og@mail.gmail.com
обсуждение исходный текст
Ответ на Inconsistent behavior in serializable snapshot  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Список pgsql-hackers
On Sun, Mar 11, 2018 at 7:52 PM, Kuntal Ghosh
<kuntalghosh.2007@gmail.com> wrote:
> Hello hackers,
>
> While working on serializable transaction isolation, I've noticed some
> strange behavior in the first permutation mentioned in
> isolation/specs/read-only-anomaly-2.spec file.
>
> setup
> {
>     CREATE TABLE bank_account (id TEXT PRIMARY KEY, balance DECIMAL NOT NULL);
>     INSERT INTO bank_account (id, balance) VALUES ('X', 0), ('Y', 0);
> }
>
> # without s3, s1 and s2 commit
> permutation "s2rx" "s2ry" "s1ry" "s1wy" "s1c" "s2wx" "s2c" "s3c"
>
> Here, we can see a serial order T1 <- T2 without any conflict.
> However, if I perform "VACUUM FREEZE bank_account" after the setup
> step, s2wx throws a conflict error:
> ERROR:  could not serialize access due to read/write dependencies
> among transactions
> DETAIL:  Reason code: Canceled on identification as a pivot, during write.
> HINT:  The transaction might succeed if retried.
>
> Is this an expected behavior?
Got the answer.

In this case, when we perform VACUUM FREEZE on the table, the planner
chooses a plan with sequential scan(instead of Index Scan) to scan the
table for SELECT and UPDATE statements. Hence, we've to take relation
level SIReadLock instead of page and tuple level SIReadLock. This
causes the serialization conflict.


-- 
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com


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

Предыдущее
От: amul sul
Дата:
Сообщение: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)