You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Denis Chudov (Jira)" <ji...@apache.org> on 2022/12/22 15:36:00 UTC

[jira] [Commented] (IGNITE-18057) Sql. Fix index scan transactional consistency.

    [ https://issues.apache.org/jira/browse/IGNITE-18057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651322#comment-17651322 ] 

Denis Chudov commented on IGNITE-18057:
---------------------------------------

[~v.pyatkov] lgtm

> 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
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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)