[
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)