[
https://issues.apache.org/jira/browse/IGNITE-24368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Shergalis updated IGNITE-24368:
---------------------------------------
Description:
PartitionListener and PartitionReplicaListener contain write intent switch
logic (which is called on transaction cleanup). This logic calls
TableUtils#indexIdsAtRwTxBeginTs() which tries to get Catalog version
corresponding to the moment when the transaction in question was started. But
Catalog compactor does not account for not-yet-resolved write intents (and it
is designed in this way), so, when such a cleanup attempts happens, the
corresponding Catalog version might already be truncated, which causes the
write intent switch attempt to fail.
The scenario is like this:
# Table A is created (Catalog version is N)
# Transaction tx1 is started, an insert to A is made, the transaction is
committed
# Table B is created (Catalog version becomes N+p, so N is not the latest
catalog version anymore)
# Enough time passes for Catalog version N activation ts to become lower than
LWM
# Catalog compactor truncates Catalog version N
# Cleanup is started for tx1; it tries to get Catalog version for startTs(tx1)
which is N, and fails, as N was already compacted out
We could try to use IndexMetaStorage to get the list of indices for a table in
question at startTs(tx) as it contains all the needed information.
Dirty fixed in IGNITE-24368
was:
PartitionListener and PartitionReplicaListener contain write intent switch
logic (which is called on transaction cleanup). This logic calls
TableUtils#indexIdsAtRwTxBeginTs() which tries to get Catalog version
corresponding to the moment when the transaction in question was started. But
Catalog compactor does not account for not-yet-resolved write intents (and it
is designed in this way), so, when such a cleanup attempts happens, the
corresponding Catalog version might already be truncated, which causes the
write intent switch attempt to fail.
The scenario is like this:
# Table A is created (Catalog version is N)
# Transaction tx1 is started, an insert to A is made, the transaction is
committed
# Table B is created (Catalog version becomes N+p, so N is not the latest
catalog version anymore)
# Enough time passes for Catalog version N activation ts to become lower than
LWM
# Catalog compactor truncates Catalog version N
# Cleanup is started for tx1; it tries to get Catalog version for startTs(tx1)
which is N, and fails, as N was already compacted out
We could try to use IndexMetaStorage to get the list of indices for a table in
question at startTs(tx) as it contains all the needed information.
> Transaction cleanup might fail due to missing Catalog version
> -------------------------------------------------------------
>
> Key: IGNITE-24368
> URL: https://issues.apache.org/jira/browse/IGNITE-24368
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> PartitionListener and PartitionReplicaListener contain write intent switch
> logic (which is called on transaction cleanup). This logic calls
> TableUtils#indexIdsAtRwTxBeginTs() which tries to get Catalog version
> corresponding to the moment when the transaction in question was started. But
> Catalog compactor does not account for not-yet-resolved write intents (and it
> is designed in this way), so, when such a cleanup attempts happens, the
> corresponding Catalog version might already be truncated, which causes the
> write intent switch attempt to fail.
> The scenario is like this:
> # Table A is created (Catalog version is N)
> # Transaction tx1 is started, an insert to A is made, the transaction is
> committed
> # Table B is created (Catalog version becomes N+p, so N is not the latest
> catalog version anymore)
> # Enough time passes for Catalog version N activation ts to become lower
> than LWM
> # Catalog compactor truncates Catalog version N
> # Cleanup is started for tx1; it tries to get Catalog version for
> startTs(tx1) which is N, and fails, as N was already compacted out
> We could try to use IndexMetaStorage to get the list of indices for a table
> in question at startTs(tx) as it contains all the needed information.
>
> Dirty fixed in IGNITE-24368
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
