[
https://issues.apache.org/jira/browse/IGNITE-18019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-18019:
-----------------------------------
Description:
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.
was:
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. But when it
comes to others - my concerns are listed in the Epic.
> 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
> 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)
