Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
6.3.1
-
None
-
10.0.20
Description
Consider this query:
select p_brand, p_type, p_size
|
from v_partsupp, v_part
|
where p_partkey = ps_partkey
|
and ps_suppkey NOT IN
|
( select s_suppkey
|
from v_supplier
|
where s_comment like '%Customer%Complaints%' ) |
limit 10; |
|
With version 6.2.3-1, this query completes correctly. With version 6.3.1 (unreleased) it raises sig6 SIGABT.
If written to use IN rather than NOT IN, the the SIGABT does not happen.
Some analysis shows that the underlying problem has always existed. Starting with 6.3.1, we have enabled more extensive array checking, and this exposes the problem.
In tuplejoiner.cpp around line 604, we find:
if (UNLIKELY(inUM() && (joinType & MATCHNULLS) && !isNull && !typelessJoin)) |
{
|
if (smallRG.getColType(largeKeyColumns[0]) == CalpontSystemCatalog::LONGDOUBLE) |
|
There is no guarantee that the index in largeKeyColumns is a valid index in smallRG. largeKeyColumns[n] should only be used to index into largeRG, not smallRG.
So the task here is to determine whether the author intended to comapare smallRG to smallKeyColumns[0] or should it be largeRG to largeKeyColumns[0]. Frankly, in this particular context, it may not matter, but it is important that we compare apples to apples.