| commit | 784971c018c2dc44c53d7c0f366ad49cd8681ac6 | [log] [tgz] |
|---|---|---|
| author | Venu Reddy <k.venureddy2103@gmail.com> | Thu Feb 29 03:53:14 2024 +0530 |
| committer | Impala Public Jenkins <impala-public-jenkins@cloudera.com> | Sun Mar 03 07:02:50 2024 +0000 |
| tree | 19f76ee7b103b7b2c5fa5263a7f392a3d0f759dc | |
| parent | 96964be7a31a78058dea08b43c3b4115fb93dea7 [diff] |
IMPALA-12851: Fix AllocWriteIdEvent process issue to add txnId-tableWriteIds mapping During AllocWriteIdEvent process, txnId to tableWriteIds mapping is not added to catalog in the following cases: 1. When CREATE_TABLE event is followed by ALLOC_WRITE_ID_EVENT for the table in the same batch of MetastoreEventsProcessor.processEvents(), process AllocWriteIdEvent cannot find catalog table since CREATE_TABLE is not processed by the time of AllocWriteIdEvent object construction. 2. When catalog table is present. But it is not loaded. This patch fixes: 1. Removes the usage of get table from catalog in all the event constructors. Currently, AllocWriteIdEvent, ReloadEvent, CommitCompactionEvent get the catalog table in their constructors. 2. Adds the txnId to tableWriteIds mapping in catalog even when table is not loaded. And ensures the write ids are not added to table if it is a non-partitioned table. 3. Also fixed a bug in TableWriteId's hashCode() implementation that is breaking hashcode contract. Two same TableWriteId of different instances produce different hashcode though they are equal. 4. Fixed CatalogHmsSyncToLatestEventIdTest.cleanUp() issue. flagInvalidateCache and flagSyncToLatestEventId are incorrectly set in cleanUp. Testing: - Added tests in MetastoreEventsProcessorTest Change-Id: I8b1a918befd4ee694880fd4e3cc04cb55b64955f Reviewed-on: http://gerrit.cloudera.org:8080/21087 Reviewed-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Lightning-fast, distributed SQL queries for petabytes of data stored in open data and table formats.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
The fastest way to try out Impala is a quickstart Docker container. You can try out running queries and processing data sets in Impala on a single machine without installing dependencies. It can automatically load test data sets into Apache Kudu and Apache Parquet formats and you can start playing around with Apache Impala SQL within minutes.
To learn more about Impala as a user or administrator, or to try Impala, please visit the Impala homepage. Detailed documentation for administrators and users is available at Apache Impala documentation.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment. Impala supports x86_64 and has experimental support for arm64 (as of Impala 4.0). Impala Requirements contains more detailed information on the minimum CPU requirements.
Impala runs on Linux systems only. The supported distros are
Other systems, e.g. SLES12, may also be supported but are not tested by the community.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.
See Impala's developer documentation to get started.
Detailed build notes has some detailed information on the project layout and build.