[jira] [Assigned] (IGNITE-18019) Add MV partition storage GC API

["Ivan Bessonov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-18019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivan Bessonov reassigned IGNITE-18019:
--------------------------------------

    Assignee: Ivan Bessonov

> Add MV partition storage GC API
> -------------------------------
>
>                 Key: IGNITE-18019
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18019
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Ivan Bessonov
>            Assignee: Ivan Bessonov
>            Priority: Major
>              Labels: ignite-3
>
> Please refer to the Epic for detailed description.
> In this issue I expect:
>  * a new method in MvPartitionStorage that performs GC on a single row
>  * a set of tests for this method, including concurrent scan and GC, a situation that may happen in real life and can cause real problems
>  * implementation of the method in the test storage
> More on tests:
>  * I would prefer a separate class, regular abstract partition test is too bloated
>  * concurrent scenario that I mean. In parallel with GC trying to update a row:
>  ** user may add a write intent
>  *** old write intent was there
>  *** old write intent wasn't there
>  ** user may commit existing write intent
>  ** user may abort existing write intent
>  ** user may read row
>  ** user may scan index that uses this row to resolve the validity of the value
> What can go wrong in these scenarios?
>  # Version chain's head is updated
>  # Something is removed from the chain while other thread reads it
> I don't think that there will be any issues in the test storage. Data is not deleted, all we need is a bunch of null-checks.
> But when it comes to others - my concerns are listed in the Epic.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)