You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladislav Pyatkov (Jira)" <ji...@apache.org> on 2022/12/20 09:50:00 UTC
[jira] [Assigned] (IGNITE-18057) Sql. Fix index scan transactional consistency.
[ https://issues.apache.org/jira/browse/IGNITE-18057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vladislav Pyatkov reassigned IGNITE-18057:
------------------------------------------
Assignee: Vladislav Pyatkov
> Sql. Fix index scan transactional consistency.
> ----------------------------------------------
>
> Key: IGNITE-18057
> URL: https://issues.apache.org/jira/browse/IGNITE-18057
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Andrey Mashenkov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> According to tx protocol in order to prevent phantom reads we should lock current key on every iteration that may be bigger than upper bound border.
> Let's check following example:
> tbl [3, 5, 8]
> select * from tbl where k >= 3 and k <= 7 may be internally converted to sorted index scan (lowerBorder=3[included], upperBorder=7[included])
> thus we won't see key 8 and won't lock it.
> That means that tx2 may insert key 6, so that we finish with phantom read anomaly on select * from tbl where k >= 3 and k <= 7 re-run.
> h3. Definition of Done
> Aforementioned scenario won't lead to phantom read.
> h3. Implementation Notes
> We should lock ceil(upper bound key) or +INF if there's no such key, thus we should iterate over sorted index without upper bound parameter manually comparing next key with users upperBound.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)