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)