[jira] [Created] (HIVE-27175) Fix TestJdbcDriver2#testSelectExecAsync2
Vihang Karajgaonkar created HIVE-27175: -- Summary: Fix TestJdbcDriver2#testSelectExecAsync2 Key: HIVE-27175 URL: https://issues.apache.org/jira/browse/HIVE-27175 Project: Hive Issue Type: Sub-task Reporter: Vihang Karajgaonkar Assignee: Vihang Karajgaonkar TestJdbcDriver2#testSelectExecAsync2 is failing on branch-3. We need to backport HIVE-20897 to fix it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Move Jira notification emails out of dev@hive
+1, Thanx Stamatis for starting the thread -Ayush > On 25-Mar-2023, at 3:57 PM, Stamatis Zampetakis wrote: > > Hi everyone, > > In the last Hive board report someone mentioned that the volume of Jira > notification emails to the dev list is huge especially when compared to > emails send by actual humans making it hard for someone to follow what's > happening in the project. > > I personally share their viewpoint. For a long time I have been relying on > client side (Gmail) filters to separate Jira notifications from other > emails to the dev list. > > I think it would be better to direct the traffic from jira to a separate > list namely jira@hive to keep the dev@hive list clean and dedicated to > human interaction. > > What do you think? > > Best, > Stamatis
[DISCUSS] Move Jira notification emails out of dev@hive
Hi everyone, In the last Hive board report someone mentioned that the volume of Jira notification emails to the dev list is huge especially when compared to emails send by actual humans making it hard for someone to follow what's happening in the project. I personally share their viewpoint. For a long time I have been relying on client side (Gmail) filters to separate Jira notifications from other emails to the dev list. I think it would be better to direct the traffic from jira to a separate list namely jira@hive to keep the dev@hive list clean and dedicated to human interaction. What do you think? Best, Stamatis
Re: [DISCUSS] HIVE 4.0 GA Release Proposal
Regarding correctness, I think it makes sense to change default values and possibly add a warning note when there's a known risk of wrong results. Needless to say that we should try to fix as many issues as possible; we still need volunteers to review open PRS. Performances regressions are trickier but if we have the query plans (CBO + full) along with logs (including task counters) for fast and slow execution we may be able to understand what happens. Don't hesitate to create Jira tickets with these information if available. Last regarding 4.0.0 blockers, I don't think we need a special label. The built-in and widely used priority "blocker" seems enough to capture the importance and urgency of a ticket. Since I am the release manager for the next release I will go over tickets marked as blockers and reevaluate priorities if necessary. Best, Stamatis On Thu, Mar 23, 2023, 10:27 AM Denys Kuzmenko wrote: > Thanks, Sungwoo for running the TPC-DS benchmark. Do we know if the same > level of performance degradation was present in 4.0.0-alpha1? > > All: please use the `hive-4.0.0-must` label in a ticket if you think it's > a show-stopper for the release. >
[jira] [Created] (HIVE-27174) Disable sysdb.q test
Aman Raj created HIVE-27174:
---
Summary: Disable sysdb.q test
Key: HIVE-27174
URL: https://issues.apache.org/jira/browse/HIVE-27174
Project: Hive
Issue Type: Sub-task
Reporter: Aman Raj
Assignee: Aman Raj
h3. What changes were proposed in this pull request?
Disabled sysdb.q test. The test is failing because of diff in
BASIC_COLUMN_STATS json string.
Client Execution succeeded but contained differences (error code = 1) after
executing sysdb.q
3803,3807c3803,3807
< COLUMN_STATS_ACCURATE org.apache.derby.impl.jdbc.EmbedClob@125b285b
< COLUMN_STATS_ACCURATE org.apache.derby.impl.jdbc.EmbedClob@471246f3
< COLUMN_STATS_ACCURATE org.apache.derby.impl.jdbc.EmbedClob@57c013
< COLUMN_STATS_ACCURATE org.apache.derby.impl.jdbc.EmbedClob@59f1d7ac
< COLUMN_STATS_ACCURATE org.apache.derby.impl.jdbc.EmbedClob@71a0
—
{quote}COLUMN_STATS_ACCURATE
\{"BASIC_STATS":"true","COLUMN_STATS":{"c_boolean":"true","c_float":"true","c_int":"true","key":"true","value":"true"}}
COLUMN_STATS_ACCURATE
\{"BASIC_STATS":"true","COLUMN_STATS":{"c_boolean":"true","c_float":"true","c_int":"true","key":"true","value":"true"}}
COLUMN_STATS_ACCURATE
\{"BASIC_STATS":"true","COLUMN_STATS":{"key":"true","value":"true"}}
COLUMN_STATS_ACCURATE
\{"BASIC_STATS":"true","COLUMN_STATS":{"key":"true","value":"true"}}
COLUMN_STATS_ACCURATE {"BASIC_STATS":"true","COLUMN_STATS":
{quote}
h3. Why are the changes needed?
There is no issue in the test. The current code prints the COL_STATS as an
Object instead of a json string. Not sure why is this case. Tried a lot of ways
but seems like this is not fixable at the moment. So, disabling it for now.
Note that, in Hive 3.1.3 release this test was disabled so there should not be
any issue in disabling it here.
Created a followup ticket to fix this test that can be taken up later -
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
