You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Evgeny Stanilovsky (Jira)" <ji...@apache.org> on 2023/02/08 08:14:00 UTC
[jira] [Updated] (IGNITE-18194) Scan chooses incorrect timestamp to scan storage in RO transaction
[ https://issues.apache.org/jira/browse/IGNITE-18194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evgeny Stanilovsky updated IGNITE-18194:
----------------------------------------
Summary: Scan chooses incorrect timestamp to scan storage in RO transaction (was: Scan chooses incorerect timestamp to scan storage in RO transaction)
> Scan chooses incorrect timestamp to scan storage in RO transaction
> ------------------------------------------------------------------
>
> Key: IGNITE-18194
> URL: https://issues.apache.org/jira/browse/IGNITE-18194
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> Method _PartitionReplicaListener.retrieveExactEntriesUntilCursorEmpty_ creates a cursor over storage using _HybridTimestamp.MAX_VALUE_ timestamp, but required to use a timestamp from request ({_}readTimestamp{_} is a timestamp from read request here).
> Also, this scenario is not covered by test, because TC is green. Need to write a test scenario that demonstrate issue when storage cursor is opened with incorrect timestamp in RO transaction.
> h3. Implementation Notes
> >>Also, this scenario is not covered by test, because TC is green. Need to write a test scenario that demonstrate issue when storage cursor is opened with incorrect timestamp in RO transaction.
> Seems that we already have such test org.apache.ignite.internal.table.TxAbstractTest#testReadOnlyGetWriteIntentResolutionUpdate
--
This message was sent by Atlassian Jira
(v8.20.10#820010)