[
https://issues.apache.org/jira/browse/KUDU-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048528#comment-16048528
]
Todd Lipcon commented on KUDU-791:
----------------------------------
This is causing some flakiness of alter_table-test's TestReplicatedAlter test
case. The issue is that we issue an alter-table and then immediately scan on
the leader. However the leader may not have yet committed the altertable.
I tried changing the test to SCAN_AT_SNAPSHOT but that also doesn't work
because the ScanSpec creation (evaluation of the client projection) is done
before the "wait for snapshot" code path. I'm also not sure the "wait for
snapshot" part would correctly wait for an in-flight alter operation.
I'll change the test in the meantime to use an AssertEventually(...) so it's
not flaky, and leave a marker back to this bug.
> Consistency for alter table operations
> --------------------------------------
>
> Key: KUDU-791
> URL: https://issues.apache.org/jira/browse/KUDU-791
> Project: Kudu
> Issue Type: Sub-task
> Components: client, tserver
> Affects Versions: Backlog
> Reporter: Dan Burkert
>
> This should include client timestamp propagation on schema alter.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
