Re: Inconsistent behavior in serializable snapshot - Mailing list pgsql-hackers

From Kuntal Ghosh
Subject Re: Inconsistent behavior in serializable snapshot
Date
Msg-id CAGz5QC+E_o=9Kx4+syVaSt4afMopTTjNJm_Z-oVEfagk0mt_Og@mail.gmail.com
Whole thread Raw
In response to Inconsistent behavior in serializable snapshot  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
List 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 by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Next
From: Andrey Borodin
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)