You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Denis Chudov (Jira)" <ji...@apache.org> on 2023/02/08 14:14:00 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17685912#comment-17685912 ]
Denis Chudov commented on IGNITE-18194:
---------------------------------------
[~v.pyatkov] LGTM.
> 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)