[jira] [Commented] (IMPALA-10936) StmtMetadataLoader::collectPolicyTables() should handle FailedLoadLocalTable without NPE
[
https://issues.apache.org/jira/browse/IMPALA-10936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423440#comment-17423440
]
ASF subversion and git services commented on IMPALA-10936:
--
Commit 4b8bb041b95529a8147981e7ca2c392e07611b2f in impala's branch
refs/heads/master from stiga-huang
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=4b8bb04 ]
IMPALA-10936: Fix NPE in collecting policy tables on FailedLoadLocalTable
Ranger column-masking/row-filtering policies can have complex
expressions that reference other tables (e.g. by using subqueries). So
when loading metadata of a table, we also need to load all tables
referenced by its related policies (i.e. "policy tables"). This requires
getting all its columns so we can get the column-masking policies.
However, for a failed loaded table in LocalCatalog mode, the table is
represented by a FailedLoadLocalTable which has a null ColumnMap. This
causes a NullPointerException when collecting policy tables for it.
This patch skips collecting policy tables on failed loaded tables. Also
add some null checks in LocalTable in case its ColumnMap is null. So
FailedLoadLocalTable can have the same robustness as IncompleteTable
which is the failed table representation in the legacy catalog mode.
Tests:
- Manually verified the NPE disappear in logs
- Added FE unit test
Change-Id: I7a6cd567685920211f05f2fdaac96bc98da41ac6
Reviewed-on: http://gerrit.cloudera.org:8080/17888
Reviewed-by: Joe McDonnell
Tested-by: Impala Public Jenkins
> StmtMetadataLoader::collectPolicyTables() should handle FailedLoadLocalTable
> without NPE
>
>
> Key: IMPALA-10936
> URL: https://issues.apache.org/jira/browse/IMPALA-10936
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 4.1.0
>Reporter: Joe McDonnell
>Assignee: Quanlong Huang
>Priority: Major
>
> If table loading fails, then it result in a FailedLoadLocalTable, which uses
> this constructor for LocalTable:
> {noformat}
> protected LocalTable(LocalDb db, String tblName) {
> this.db_ = Preconditions.checkNotNull(db);
> this.name_ = tblName;
> this.ref_ = null;
> this.msTable_ = null;
> this.cols_ = null;
> this.tableStats_ = null;
> }{noformat}
> Since cols_ and other fields are null, the code in
> StmtMetadataLoader::collectPolicyTables(), which calls
> LocalTable::getColumnsInHiveOrder() will throw a NullPointerException when
> trying to access cols_ in getNonClusteringColumns().
> This will fail the query with a NullPointerException, even though the
> underlying problem came from failing to load the table metadata. We should
> handle this to avoid the NullPointerException. That may happen as part of
> StmtMetadataLoader::collectPolicyTables() or
> StmtMetadataLoader::getMissingTables().
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10951) Upgrade third-party libraries for Impala native toolchain
Wenzhe Zhou created IMPALA-10951: Summary: Upgrade third-party libraries for Impala native toolchain Key: IMPALA-10951 URL: https://issues.apache.org/jira/browse/IMPALA-10951 Project: IMPALA Issue Type: Sub-task Components: Backend Affects Versions: Impala 4.1.0 Reporter: Wenzhe Zhou Assignee: Wenzhe Zhou Fix For: Impala 4.1.0 Some of third party libraries in Impala native tool-chains are be older than the ones in Kudu repo. We need to upgrade these libraries since Kudu code use some new APIs in these libraries. We should upgrade these libraries as their own separate change. These bigger changes tend to have preparation patches to line things up, then the switchover. We need to upgrade following libraries: boost, glog, google's protobuf. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10951) Upgrade third-party libraries for Impala native toolchain
Wenzhe Zhou created IMPALA-10951: Summary: Upgrade third-party libraries for Impala native toolchain Key: IMPALA-10951 URL: https://issues.apache.org/jira/browse/IMPALA-10951 Project: IMPALA Issue Type: Sub-task Components: Backend Affects Versions: Impala 4.1.0 Reporter: Wenzhe Zhou Assignee: Wenzhe Zhou Fix For: Impala 4.1.0 Some of third party libraries in Impala native tool-chains are be older than the ones in Kudu repo. We need to upgrade these libraries since Kudu code use some new APIs in these libraries. We should upgrade these libraries as their own separate change. These bigger changes tend to have preparation patches to line things up, then the switchover. We need to upgrade following libraries: boost, glog, google's protobuf. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMPALA-10940) Pick parts of recent gutil changes from Kudu repo
[ https://issues.apache.org/jira/browse/IMPALA-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wenzhe Zhou updated IMPALA-10940: - Parent: IMPALA-10931 Issue Type: Sub-task (was: Improvement) > Pick parts of recent gutil changes from Kudu repo > - > > Key: IMPALA-10940 > URL: https://issues.apache.org/jira/browse/IMPALA-10940 > Project: IMPALA > Issue Type: Sub-task > Components: Backend >Affects Versions: Impala 4.1.0 >Reporter: Wenzhe Zhou >Assignee: Wenzhe Zhou >Priority: Major > Fix For: Impala 4.1.0 > > > We plan to rebase source code of be/src/kudu from Kudu upstream. Kudu code > use some new functionalities which were added in kudu/gutil. We have to pick > these changes from Kudu before rebasing be/src/kudu. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-10926) Sync db/table to latest event id for ddl operations in catalog metastore server
[ https://issues.apache.org/jira/browse/IMPALA-10926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423431#comment-17423431 ] Sourabh Goyal commented on IMPALA-10926: Patch for review: https://gerrit.cloudera.org/c/17859 > Sync db/table to latest event id for ddl operations in catalog metastore > server > --- > > Key: IMPALA-10926 > URL: https://issues.apache.org/jira/browse/IMPALA-10926 > Project: IMPALA > Issue Type: Task >Reporter: Sourabh Goyal >Assignee: Sourabh Goyal >Priority: Major > > Whenever DDL operations like add/remove partitions, alter table etc are > performed from catalog HMS endpoints, we will do the following: > # Acquire lock on db/table > # Perform HMS operation > # For db/table in step 1, fetch all events from HMS > # Apply those events on the db/table in catalogd cache > # Set the last processed event id for db/table > In addition to the above, the following needs to be handled as well: > # Event processor should skip processing an event on a db/table if the > db/table is already synced till that event id. > # If last synced event id in table/db is less than the event being processed > by event processor, it should set the last synced db/table event id after > successfully processing the event. > # Full table refresh should set the last event processed. > cc - [~kishendas] [~vihangk1] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10950) expr-benchmark.cc needs some update
Riza Suminto created IMPALA-10950:
-
Summary: expr-benchmark.cc needs some update
Key: IMPALA-10950
URL: https://issues.apache.org/jira/browse/IMPALA-10950
Project: IMPALA
Issue Type: Bug
Reporter: Riza Suminto
Assignee: Riza Suminto
expr-benchmark compiles, but crash when it is executed.
This is because the scalar expression's thrift definition has moved from
{code:java}
query_request.plan_exec_info[0].fragments[0].output_sink.output_exprs{code}
to
{code:java}
query_request.plan_exec_info[0].fragments[0].plan.nodes[0].union_node.const_expr_lists[0]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10950) expr-benchmark.cc needs some update
Riza Suminto created IMPALA-10950:
-
Summary: expr-benchmark.cc needs some update
Key: IMPALA-10950
URL: https://issues.apache.org/jira/browse/IMPALA-10950
Project: IMPALA
Issue Type: Bug
Reporter: Riza Suminto
Assignee: Riza Suminto
expr-benchmark compiles, but crash when it is executed.
This is because the scalar expression's thrift definition has moved from
{code:java}
query_request.plan_exec_info[0].fragments[0].output_sink.output_exprs{code}
to
{code:java}
query_request.plan_exec_info[0].fragments[0].plan.nodes[0].union_node.const_expr_lists[0]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IMPALA-10949) Improve batching logic of events
Vihang Karajgaonkar created IMPALA-10949: Summary: Improve batching logic of events Key: IMPALA-10949 URL: https://issues.apache.org/jira/browse/IMPALA-10949 Project: IMPALA Issue Type: Improvement Reporter: Vihang Karajgaonkar This is a followup based on the review comment https://gerrit.cloudera.org/#/c/17848/2/fe/src/main/java/org/apache/impala/catalog/events/MetastoreEvents.java@1641 Current approach of batching batches together the events from a single operation so that self-event check is done per-batch. However, it looks like there is a considerable scope of improving the batching logic by clubbing together accross the various sources of the events on a table when IMPALA-10926 is merged. After IMPALA-10926 each table will track the last_synced_event and then the events processor can simply ignore a event which <= the last_synced_event. This simplification of self-events logic will enable easier batching for all the events of a type on a table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10949) Improve batching logic of events
Vihang Karajgaonkar created IMPALA-10949: Summary: Improve batching logic of events Key: IMPALA-10949 URL: https://issues.apache.org/jira/browse/IMPALA-10949 Project: IMPALA Issue Type: Improvement Reporter: Vihang Karajgaonkar This is a followup based on the review comment https://gerrit.cloudera.org/#/c/17848/2/fe/src/main/java/org/apache/impala/catalog/events/MetastoreEvents.java@1641 Current approach of batching batches together the events from a single operation so that self-event check is done per-batch. However, it looks like there is a considerable scope of improving the batching logic by clubbing together accross the various sources of the events on a table when IMPALA-10926 is merged. After IMPALA-10926 each table will track the last_synced_event and then the events processor can simply ignore a event which <= the last_synced_event. This simplification of self-events logic will enable easier batching for all the events of a type on a table. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMPALA-10948) Impala shouldn't require DECIMAL scale for Parquet files
Zoltán Borók-Nagy created IMPALA-10948: -- Summary: Impala shouldn't require DECIMAL scale for Parquet files Key: IMPALA-10948 URL: https://issues.apache.org/jira/browse/IMPALA-10948 Project: IMPALA Issue Type: Bug Components: Backend Reporter: Zoltán Borók-Nagy Impala requires the 'scale' to be set for decimal columns: https://github.com/apache/impala/blob/1a61a8025c87c37921a1bba4c49f754d8bd10bcc/be/src/exec/parquet/parquet-metadata-utils.cc#L332 But it is only an optional field in Parquet's [SchemaElement|https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift#L392] and the [docs|https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#decimal] says that if the scale is unspecified then it should be considered to be 0. Then there's the new logical type annotation [DecimalType|https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift#L253], but Impala doesn't use it during scans. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10948) Impala shouldn't require DECIMAL scale for Parquet files
Zoltán Borók-Nagy created IMPALA-10948: -- Summary: Impala shouldn't require DECIMAL scale for Parquet files Key: IMPALA-10948 URL: https://issues.apache.org/jira/browse/IMPALA-10948 Project: IMPALA Issue Type: Bug Components: Backend Reporter: Zoltán Borók-Nagy Impala requires the 'scale' to be set for decimal columns: https://github.com/apache/impala/blob/1a61a8025c87c37921a1bba4c49f754d8bd10bcc/be/src/exec/parquet/parquet-metadata-utils.cc#L332 But it is only an optional field in Parquet's [SchemaElement|https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift#L392] and the [docs|https://github.com/apache/parquet-format/blob/master/LogicalTypes.md#decimal] says that if the scale is unspecified then it should be considered to be 0. Then there's the new logical type annotation [DecimalType|https://github.com/apache/parquet-format/blob/master/src/main/thrift/parquet.thrift#L253], but Impala doesn't use it during scans. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMPALA-10947) SQL support for querying Iceberg metadata
Zoltán Borók-Nagy created IMPALA-10947: -- Summary: SQL support for querying Iceberg metadata Key: IMPALA-10947 URL: https://issues.apache.org/jira/browse/IMPALA-10947 Project: IMPALA Issue Type: New Feature Components: Frontend Reporter: Zoltán Borók-Nagy HIVE-25457 added support for querying Iceberg table metadata to Hive. They support the following syntax: SELECT * FROM default.iceberg_table.history; Spark uses the same syntax: https://iceberg.apache.org/spark-queries/#history Other than "history", the following metadata tables are available in Iceberg: The following metadata tables are available in Iceberg: * ENTRIES, * FILES, * HISTORY, * SNAPSHOTS, * MANIFESTS, * PARTITIONS, * ALL_DATA_FILES, * ALL_MANIFESTS, * ALL_ENTRIES Impala currently only supports "DESCRIBE HISTORY ". The above SELECT syntax would be more convenient for the users, also it would be more flexible as users could easily define filters in WHERE clauses. And of course we would be consistent with other engines. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10947) SQL support for querying Iceberg metadata
Zoltán Borók-Nagy created IMPALA-10947: -- Summary: SQL support for querying Iceberg metadata Key: IMPALA-10947 URL: https://issues.apache.org/jira/browse/IMPALA-10947 Project: IMPALA Issue Type: New Feature Components: Frontend Reporter: Zoltán Borók-Nagy HIVE-25457 added support for querying Iceberg table metadata to Hive. They support the following syntax: SELECT * FROM default.iceberg_table.history; Spark uses the same syntax: https://iceberg.apache.org/spark-queries/#history Other than "history", the following metadata tables are available in Iceberg: The following metadata tables are available in Iceberg: * ENTRIES, * FILES, * HISTORY, * SNAPSHOTS, * MANIFESTS, * PARTITIONS, * ALL_DATA_FILES, * ALL_MANIFESTS, * ALL_ENTRIES Impala currently only supports "DESCRIBE HISTORY ". The above SELECT syntax would be more convenient for the users, also it would be more flexible as users could easily define filters in WHERE clauses. And of course we would be consistent with other engines. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IMPALA-10674) Update toolchain ORC libary for better Iceberg support
[ https://issues.apache.org/jira/browse/IMPALA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltán Borók-Nagy resolved IMPALA-10674. Fix Version/s: Impala 4.1.0 Resolution: Fixed > Update toolchain ORC libary for better Iceberg support > -- > > Key: IMPALA-10674 > URL: https://issues.apache.org/jira/browse/IMPALA-10674 > Project: IMPALA > Issue Type: Bug > Components: Backend, Infrastructure >Reporter: Zoltán Borók-Nagy >Assignee: Zoltán Borók-Nagy >Priority: Major > Fix For: Impala 4.1.0 > > > We need the following fixes/features from the ORC library: > ORC-763: Fix timestamp inconsistencies with Java > ORC-784: Support setting timezone to timestamp column > ORC-666: Support timastamp with local timezone (this corresponds to the > Iceberg TIMESTAMPTZ type) > ORC-781: Make type annotations available from C++ (this is needed for Iceberg > column resolution) > To get these we need to upgrade/patch the ORC C++ library in the toolchain. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-10674) Update toolchain ORC libary for better Iceberg support
[ https://issues.apache.org/jira/browse/IMPALA-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltán Borók-Nagy resolved IMPALA-10674. Fix Version/s: Impala 4.1.0 Resolution: Fixed > Update toolchain ORC libary for better Iceberg support > -- > > Key: IMPALA-10674 > URL: https://issues.apache.org/jira/browse/IMPALA-10674 > Project: IMPALA > Issue Type: Bug > Components: Backend, Infrastructure >Reporter: Zoltán Borók-Nagy >Assignee: Zoltán Borók-Nagy >Priority: Major > Fix For: Impala 4.1.0 > > > We need the following fixes/features from the ORC library: > ORC-763: Fix timestamp inconsistencies with Java > ORC-784: Support setting timezone to timestamp column > ORC-666: Support timastamp with local timezone (this corresponds to the > Iceberg TIMESTAMPTZ type) > ORC-781: Make type annotations available from C++ (this is needed for Iceberg > column resolution) > To get these we need to upgrade/patch the ORC C++ library in the toolchain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IMPALA-10946) RECOVER PARTITIONS might create non-existing partitions
[
https://issues.apache.org/jira/browse/IMPALA-10946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltán Borók-Nagy updated IMPALA-10946:
---
Labels: ramp-up (was: )
> RECOVER PARTITIONS might create non-existing partitions
> ---
>
> Key: IMPALA-10946
> URL: https://issues.apache.org/jira/browse/IMPALA-10946
> Project: IMPALA
> Issue Type: Bug
> Components: Catalog, Frontend
>Reporter: Zoltán Borók-Nagy
>Priority: Major
> Labels: ramp-up
>
> The following commands reproduce the bug:
> {noformat}
> create table test_table (id int)
> partitioned by (part_field string)
> stored as parquet
> LOCATION ‘/test-warehouse/abc/test’;
> insert into test_table (id, part_field) select 1, ‘abc+’;
> show partitions test_table; > it will show one partition “abc+”
> alter table test_table recover partitions;
> show partitions test_table; > result is showing two partitions, “abc” and
> “abc+”
> {noformat}
> The + character can occur anywhere in the string, RECOVER PARTITIONS will
> create a partition where the + is replaced by a space.
> Seems like other characters don't cause this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-10946) RECOVER PARTITIONS might create non-existing partitions
[
https://issues.apache.org/jira/browse/IMPALA-10946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltán Borók-Nagy updated IMPALA-10946:
---
Description:
The following commands reproduce the bug:
{noformat}
create table test_table (id int)
partitioned by (part_field string)
stored as parquet
LOCATION ‘/test-warehouse/abc/test’;
insert into test_table (id, part_field) select 1, ‘abc+’;
show partitions test_table; > it will show one partition “abc+”
alter table test_table recover partitions;
show partitions test_table; > result is showing two partitions, “abc” and
“abc+”
{noformat}
The + character can occur anywhere in the string, RECOVER PARTITIONS will
create a partition where the + is replaced by a space.
Seems like other characters don't cause this bug.
was:
The following commands reproduce the bug:
{noformat}
create table test_table (id int)
partitioned by (part_field string)
stored as parquet
LOCATION ‘/test-warehouse/abc/test’;
insert into test_table (id, part_field) select 1, ‘abc+’;
show partitions test_table; > it will show one partition “abc+”
alter table test_table recover partitions;
show partitions test_table; > result is showing two partitions, “abc” and
“abc+”
{noformat}
The '+' character can occur anywhere in the string, RECOVER PARTITIONS will
create a partition where the '+' is replaced by a space.
Seems like other characters don't cause this bug.
> RECOVER PARTITIONS might create non-existing partitions
> ---
>
> Key: IMPALA-10946
> URL: https://issues.apache.org/jira/browse/IMPALA-10946
> Project: IMPALA
> Issue Type: Bug
> Components: Catalog, Frontend
>Reporter: Zoltán Borók-Nagy
>Priority: Major
>
> The following commands reproduce the bug:
> {noformat}
> create table test_table (id int)
> partitioned by (part_field string)
> stored as parquet
> LOCATION ‘/test-warehouse/abc/test’;
> insert into test_table (id, part_field) select 1, ‘abc+’;
> show partitions test_table; > it will show one partition “abc+”
> alter table test_table recover partitions;
> show partitions test_table; > result is showing two partitions, “abc” and
> “abc+”
> {noformat}
> The + character can occur anywhere in the string, RECOVER PARTITIONS will
> create a partition where the + is replaced by a space.
> Seems like other characters don't cause this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10946) RECOVER PARTITIONS might create non-existing partitions
Zoltán Borók-Nagy created IMPALA-10946:
--
Summary: RECOVER PARTITIONS might create non-existing partitions
Key: IMPALA-10946
URL: https://issues.apache.org/jira/browse/IMPALA-10946
Project: IMPALA
Issue Type: Bug
Components: Catalog, Frontend
Reporter: Zoltán Borók-Nagy
The following commands reproduce the bug:
{noformat}
create table test_table (id int)
partitioned by (part_field string)
stored as parquet
LOCATION ‘/test-warehouse/abc/test’;
insert into test_table (id, part_field) select 1, ‘abc+’;
show partitions test_table; > it will show one partition “abc+”
alter table test_table recover partitions;
show partitions test_table; > result is showing two partitions, “abc” and
“abc+”
{noformat}
The '+' character can occur anywhere in the string, RECOVER PARTITIONS will
create a partition where the '+' is replaced by a space.
Seems like other characters don't cause this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-10946) RECOVER PARTITIONS might create non-existing partitions
Zoltán Borók-Nagy created IMPALA-10946:
--
Summary: RECOVER PARTITIONS might create non-existing partitions
Key: IMPALA-10946
URL: https://issues.apache.org/jira/browse/IMPALA-10946
Project: IMPALA
Issue Type: Bug
Components: Catalog, Frontend
Reporter: Zoltán Borók-Nagy
The following commands reproduce the bug:
{noformat}
create table test_table (id int)
partitioned by (part_field string)
stored as parquet
LOCATION ‘/test-warehouse/abc/test’;
insert into test_table (id, part_field) select 1, ‘abc+’;
show partitions test_table; > it will show one partition “abc+”
alter table test_table recover partitions;
show partitions test_table; > result is showing two partitions, “abc” and
“abc+”
{noformat}
The '+' character can occur anywhere in the string, RECOVER PARTITIONS will
create a partition where the '+' is replaced by a space.
Seems like other characters don't cause this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
