[ 
https://issues.apache.org/jira/browse/KUDU-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188576#comment-15188576
 ] 

Todd Lipcon commented on KUDU-1189:
-----------------------------------

There's some code related to this that was added in 3adecef9:

{code}
  // If present in the response, set the snapshot timestamp and the encoded last
  // primary key.  This is used when retrying the scan elsewhere.  The last
  // primary key is also updated on each scan response.
  if (is_fault_tolerant_) {
    CHECK(last_response_.has_snap_timestamp());
    snapshot_timestamp_ = last_response_.snap_timestamp();
    if (last_response_.has_last_primary_key()) {
      last_primary_key_ = last_response_.last_primary_key();
    }
  }
{code}

but perhaps we're missing integration tests, etc, so I'll leave this open.

> On reads at a snapshot that touch multiple tablets, without the user setting 
> a timestamp, use the timestamp from the first server for following scans
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KUDU-1189
>                 URL: https://issues.apache.org/jira/browse/KUDU-1189
>             Project: Kudu
>          Issue Type: Sub-task
>          Components: client
>    Affects Versions: Public beta
>            Reporter: David Alves
>            Assignee: David Alves
>            Priority: Critical
>
> When performing a READ_AT_SNAPSHOT, we allow not to set a timestamp, meaning 
> the server will pick a time. If the scan touches multiple tablets, however, 
> we don't set the timestamp assigned to the first scan on the other scans, 
> meaning each scan will have it's own timstamp, which is wrong.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to