[
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)
