[
https://issues.apache.org/jira/browse/KUDU-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18057714#comment-18057714
]
ASF subversion and git services commented on KUDU-3723:
-------------------------------------------------------
Commit 2856089dc61156b03c3cb204b84b1a2f7a503cbe in kudu's branch
refs/heads/branch-1.18.x from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=2856089dc ]
KUDU-3723 fix interpretation of new range partition specs
In the context of KUDU-2671, a new notation for specifying hash schema
of a range partition has been added. With the introduction of
range-specific hash schemas, the client side is free to send in
information on the newly added range partition as if it had a custom
hash schema, even if the new range's hash schema is the same as the
table-wide one. However, the system catalog should have normalized
the provided information, and stored the information on ranges with
the table-wide and custom hash schemas differently. The normalization
part was missing, and that was the reason for the reported issue.
This changelist addresses the problem and adds a new test scenario that
triggers an assertion without the fix.
Change-Id: Icceb138a919cd7afb572c6dd74695a3fcaaac99e
Reviewed-on: http://gerrit.cloudera.org:8080/23778
Tested-by: Alexey Serbin <[email protected]>
Reviewed-by: Alexey Serbin <[email protected]>
(cherry picked from commit cad295f98a9eb2b390eb096d34e445fb27b8cca2)
Reviewed-on: http://gerrit.cloudera.org:8080/23960
Reviewed-by: Abhishek Chennaka <[email protected]>
> Dropping and adding back same range partition right away isn't working for
> certain table schemas
> ------------------------------------------------------------------------------------------------
>
> Key: KUDU-3723
> URL: https://issues.apache.org/jira/browse/KUDU-3723
> Project: Kudu
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.17.0, 1.18.0, 1.18.1
> Reporter: Alexey Serbin
> Assignee: Alexey Serbin
> Priority: Major
>
> For a Kudu table partitioned by both range and hash, the following sequence
> leads to the table being stuck in a limbo state where it cannot be opened or
> operated by any other means, effectively rendering it inaccessible:
> * adding a new range with custom hash partition scheme
> * immediately drop the newly added range
> * immediately try adding the same range again
> The reproduction scenario is available at
> http://gerrit.cloudera.org:8080/23778 It's 100% repeatable/reproducible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
