[
https://issues.apache.org/jira/browse/HIVE-25142?focusedWorklogId=599676&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-599676
]
ASF GitHub Bot logged work on HIVE-25142:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 20/May/21 08:35
Start Date: 20/May/21 08:35
Worklog Time Spent: 10m
Work Description: pgaref commented on a change in pull request #2300:
URL: https://github.com/apache/hive/pull/2300#discussion_r635892282
##########
File path: serde/src/java/org/apache/hadoop/hive/serde2/WriteBuffers.java
##########
@@ -149,7 +149,12 @@ public int unsafeHashCode(long offset, int length) {
}
public int hashCode(long offset, int length, Position readPos) {
+ // If caller has not set the read position, then set it.
setReadPoint(offset, readPos);
+ return hashCode(length, readPos);
Review comment:
Shall we move the positioning code to the unsafeHashCode method and
remove this method? Looks like the only place its needed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 599676)
Time Spent: 20m (was: 10m)
> Rehashing in map join fast hash table causing corruption for large keys
> ------------------------------------------------------------------------
>
> Key: HIVE-25142
> URL: https://issues.apache.org/jira/browse/HIVE-25142
> Project: Hive
> Issue Type: Bug
> Components: Hive
> Reporter: mahesh kumar behera
> Assignee: mahesh kumar behera
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In map join the hash table is created using the keys. To support rehashing,
> the keys are stored in write buffer. The hash table contains the offset of
> the keys along with the hash code. When rehashing is done, the offset is
> extracted from the hash table and then hash code is generated again. For
> large keys of size greater than 255, the key length is also stored along with
> the key. In case of fast hash table implementation the way key is extracted
> is not proper. There is a code bug and thats causing the wrong key to be
> extracted and causing wrong hash code generation. This is causing the
> corruption in the hash table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
