[jira] [Resolved] (IMPALA-8593) Prohibit write to bucketed table
[ https://issues.apache.org/jira/browse/IMPALA-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yongzhi Chen resolved IMPALA-8593. -- Resolution: Fixed Fix Version/s: Impala 3.3.0 > Prohibit write to bucketed table > > > Key: IMPALA-8593 > URL: https://issues.apache.org/jira/browse/IMPALA-8593 > Project: IMPALA > Issue Type: New Feature > Components: Frontend >Affects Versions: Impala 3.1.0 >Reporter: Yongzhi Chen >Assignee: Yongzhi Chen >Priority: Critical > Labels: impala-acid > Fix For: Impala 3.3.0 > > > Impala does not support writing to bucketed tables, we need prohibit these > unsupported operations. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IMPALA-8820) start-impala-cluster can't find catalogd on recent Ubuntu 16.04
[
https://issues.apache.org/jira/browse/IMPALA-8820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-8820.
---
Resolution: Fixed
Fix Version/s: Impala 3.3.0
> start-impala-cluster can't find catalogd on recent Ubuntu 16.04
> ---
>
> Key: IMPALA-8820
> URL: https://issues.apache.org/jira/browse/IMPALA-8820
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 3.3.0
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Blocker
> Fix For: Impala 3.3.0
>
>
> We noticed a bug, first on jenkins.impala.io and then on local ubuntu 16.04
> environments where start-impala-cluster fails to find a catalogd process,
> despite the catalogd starting up fine.
> It appears that this is somehow related to an automatic update - it started
> reproducing for me after I installed the batch of packages on 2019-07-31.
> I've included the previous upgrade to illustrate the window in which this
> happened.
> {noformat}
> Start-Date: 2019-07-27 00:21:00
> Commandline: apt-get dist-upgrade
> Requested-By: tarmstrong (1000)
> Install: linux-image-4.4.0-157-generic:amd64 (4.4.0-157.185, automatic),
> linux-headers-4.4.0-157:amd64 (4.4.0-157.185, automatic),
> linux-tools-4.4.0-157:amd64 (4.4.0-157.185, automatic),
> linux-tools-4.4.0-157-generic:amd64 (4.4.0-157.185, automatic),
> linux-headers-4.4.0-157-generic:amd64 (4.4.0-157.185, automatic),
> linux-modules-extra-4.4.0-157-generic:amd64 (4.4.0-157.185, automatic),
> linux-modules-4.4.0-157-generic:amd64 (4.4.0-157.185, automatic)
> Upgrade: linux-tools-generic:amd64 (4.4.0.154.162, 4.4.0.157.165),
> linux-headers-generic:amd64 (4.4.0.154.162, 4.4.0.157.165),
> linux-libc-dev:amd64 (4.4.0-154.181, 4.4.0-157.185), mysql-client-5.7:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), mysql-server-5.7:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), libmysqlclient-dev:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), linux-image-generic:amd64
> (4.4.0.154.162, 4.4.0.157.165), mysql-server:amd64 (5.7.26-0ubuntu0.16.04.1,
> 5.7.27-0ubuntu0.16.04.1), mysql-client:amd64 (5.7.26-0ubuntu0.16.04.1,
> 5.7.27-0ubuntu0.16.04.1), mysql-client-core-5.7:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), mysql-common:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), libmysqlclient20:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), firefox:amd64
> (68.0+build3-0ubuntu0.16.04.1, 68.0.1+build1-0ubuntu0.16.04.1),
> linux-tools-common:amd64 (4.4.0-154.181, 4.4.0-157.185), patch:amd64
> (2.7.5-1ubuntu0.16.04.1, 2.7.5-1ubuntu0.16.04.2), linux-generic:amd64
> (4.4.0.154.162, 4.4.0.157.165), mysql-server-core-5.7:amd64
> (5.7.26-0ubuntu0.16.04.1, 5.7.27-0ubuntu0.16.04.1), docker-ce:amd64
> (5:19.03.0~3-0~ubuntu-xenial, 5:19.03.1~3-0~ubuntu-xenial),
> docker-ce-cli:amd64 (5:19.03.0~3-0~ubuntu-xenial, 5:19.03.1~3-0~ubuntu-xenial)
> End-Date: 2019-07-27 00:22:33
> Start-Date: 2019-07-31 12:55:00
> Commandline: apt-get dist-upgrade
> Requested-By: tarmstrong (1000)
> Upgrade: openjdk-8-jdk:amd64 (8u212-b03-0ubuntu1.16.04.1,
> 8u222-b10-1ubuntu1~16.04.1), libldap-2.4-2:amd64 (2.4.42+dfsg-2ubuntu3.5,
> 2.4.42+dfsg-2ubuntu3.6), openjdk-8-jre:amd64 (8u212-b03-0ubuntu1.16.04.1,
> 8u222-b10-1ubuntu1~16.04.1), slack-desktop:amd64 (4.0.0, 4.0.1),
> libsvn1:amd64 (1.9.3-2ubuntu1.1, 1.9.3-2ubuntu1.3),
> openjdk-8-jdk-headless:amd64 (8u212-b03-0ubuntu1.16.04.1,
> 8u222-b10-1ubuntu1~16.04.1), libsvn-perl:amd64 (1.9.3-2ubuntu1.1,
> 1.9.3-2ubuntu1.3), subversion:amd64 (1.9.3-2ubuntu1.1, 1.9.3-2ubuntu1.3),
> openjdk-8-jre-headless:amd64 (8u212-b03-0ubuntu1.16.04.1,
> 8u222-b10-1ubuntu1~16.04.1)
> End-Date: 2019-07-31 12:55:14
> {noformat}
> This issue is that the catalogd process's name is now "main", instead of
> "catalogd".
> I think we can fix by changing our scripts to fall back to checking the
> binary name.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IMPALA-8822) No metadata loading information in query profile when Catalog V2 enabled
Yongzhi Chen created IMPALA-8822: Summary: No metadata loading information in query profile when Catalog V2 enabled Key: IMPALA-8822 URL: https://issues.apache.org/jira/browse/IMPALA-8822 Project: IMPALA Issue Type: Bug Components: Catalog Affects Versions: Impala 3.2.0 Reporter: Yongzhi Chen When local catalog is enabled, we can no longer find table loading information in query profile even just after invalidate metadata for the tables. In Catalog V1, you can find the table loading information in query profile like following: Query Compilation: 4s401ms - Metadata load started: 661.084us (661.084us) - Metadata load finished. loaded-tables=1/1 load-requests=1 catalog-updates=3: 3s819ms (3s819ms) - Analysis finished: 3s820ms (763.979us) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IMPALA-8600) Reload partition does not work for transactional tables
[ https://issues.apache.org/jira/browse/IMPALA-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Kaszab resolved IMPALA-8600. -- Resolution: Fixed Fix Version/s: Impala 3.3.0 > Reload partition does not work for transactional tables > --- > > Key: IMPALA-8600 > URL: https://issues.apache.org/jira/browse/IMPALA-8600 > Project: IMPALA > Issue Type: Bug >Reporter: Vihang Karajgaonkar >Assignee: Gabor Kaszab >Priority: Major > Labels: impala-acid > Fix For: Impala 3.3.0 > > > If a table is transactional, a reload partition call should fetch the valid > writeIds. Without doing this, the reload will skip adding all the newly > created delta files of the transactional table pertaining to the new writeIds. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IMPALA-8823) Implement DROP TABLE for insert-only ACID tables
Zoltán Borók-Nagy created IMPALA-8823: - Summary: Implement DROP TABLE for insert-only ACID tables Key: IMPALA-8823 URL: https://issues.apache.org/jira/browse/IMPALA-8823 Project: IMPALA Issue Type: Improvement Reporter: Zoltán Borók-Nagy Impala currently cannot drop insert-only ACID tables. To implement DROP TABLE for insert-only tables at first we need to acquire an exclusive lock from HMS, then proceed with the usual DROP TABLE process. Heartbeating the lock might be also needed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IMPALA-8824) Impala Doc: Document DROP TABLE for Insert-only ACID Tables
Alex Rodoni created IMPALA-8824: --- Summary: Impala Doc: Document DROP TABLE for Insert-only ACID Tables Key: IMPALA-8824 URL: https://issues.apache.org/jira/browse/IMPALA-8824 Project: IMPALA Issue Type: Sub-task Components: Docs Reporter: Alex Rodoni Assignee: Alex Rodoni -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IMPALA-8812) Impala Doc: SPLIT_PART to support negative indexes
[ https://issues.apache.org/jira/browse/IMPALA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-8812. --- Resolution: Fixed Fix Version/s: Impala 3.3.0 > Impala Doc: SPLIT_PART to support negative indexes > -- > > Key: IMPALA-8812 > URL: https://issues.apache.org/jira/browse/IMPALA-8812 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_33 > Fix For: Impala 3.3.0 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (IMPALA-8780) Implementation of BufferedPlanRootSink where FlushFinal blocks until all rows are fetched
[
https://issues.apache.org/jira/browse/IMPALA-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sahil Takiar resolved IMPALA-8780.
--
Resolution: Fixed
Fix Version/s: Impala 3.3.0
Closing as fixed. We ended up referring the complete re-factoring of
IMPALA-8779 to a later patch.
> Implementation of BufferedPlanRootSink where FlushFinal blocks until all rows
> are fetched
> -
>
> Key: IMPALA-8780
> URL: https://issues.apache.org/jira/browse/IMPALA-8780
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Sahil Takiar
>Assignee: Sahil Takiar
>Priority: Major
> Fix For: Impala 3.3.0
>
>
> Implement {{BufferedPlanRootSink}} so that {{FlushFinal}} blocks until all
> rows are fetched. The implementation should use the {{RowBatchQueue}}
> introduced by IMPALA-8779. By blocking in {{FlushFinal}} all non-coordinator
> fragments will be closed if all results fit in the {{RowBatchQueue}}.
> {{BufferedPlanRootSink::Send}} should enqueue each given {{RowBatch}} onto
> the queue and then return. If the queue is full, it should block until there
> is more space left in the queue. {{BufferedPlanRootSink::GetNext}} reads from
> the queue and then fills in the given {{QueryResultSet}} by using the
> {{DataSink}} {{ScalarExprEvaluator}}-s. Since the producer thread can call
> {{BufferedPlanRootSink::Close}} while the consumer is calling
> {{BufferedPlanRootSink::GetNext}} the two methods need to be synchronized so
> that the {{DataSink}} {{MemTracker}}-s are not closed while {{GetNext}} is
> running.
> The implementation of {{BufferedPlanRootSink}} should remain the same
> regardless of whether a {{std::queue}} backed {{RowBatchQueue}} or a
> {{BufferedTupleStream}} backed {{RowBatchQueue}} is used.
> {{BufferedPlanRootSink}} and {{BlockingPlanRootSink}} are similar in the
> sense that {{BlockingPlanRootSink}} buffers one {{RowBatch}}, so for queries
> that return under 1024 rows, all non-coordinator fragments are closed
> immediately as well. The advantage of {{BufferedPlanRootSink}} is that allows
> buffering for 1+ {{RowBatch}}-es.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
