[jira] [Created] (TRAFODION-662) LP Bug: 1375902 - Incorrect range boundaries for queries using ESPs

["Alice Chen (JIRA)" <ji...@apache.org>]

Alice Chen created TRAFODION-662:
------------------------------------

             Summary: LP Bug: 1375902 - Incorrect range boundaries for queries using ESPs
                 Key: TRAFODION-662
                 URL: https://issues.apache.org/jira/browse/TRAFODION-662
             Project: Apache Trafodion
          Issue Type: Bug
          Components: sql-cmp
            Reporter: Hans Zeller
            Assignee: Hans Zeller
            Priority: Blocker
             Fix For: 0.9 (pre-incubation)


This problem was found by Dave Birdsall, this is what he said in his email. The email talks about bug 1335477, but Dave found another issue where we produce '<region b' as the start key instead of the actual starting key of the region.

I'm filing this bug for this second problem, wrong PIVs for a plan with ESP parallelism where we use a range partitioning function with ranges derived from HBase region boundaries. The bug does not happen the first time we access a table, only in subsequent queries.


From: Birdsall, Dave 
Sent: Thursday, September 04, 2014 1:08 PM
To: Du, Justin; Chen, Qifan; Neelakanthappa, Ravisha; Sharma, Anoop; Sundaresan, Sandhya
Cc: Zeller, Hans
Subject: RE: LP [Bug 1335477] : Parallel MDAM plan returns wrong results

------ NOTE from HZ: This text relates to bug 1335477

Hi,

I worked on this some this morning and over lunch.

First thing I did was pretty up the *::printBrief methods in the MDAM debug code so I could get a better picture of the MDAM tree. (MdamPoint::printBrief just prints a pointer – and not a very accurate one at that – which is next to useless. I changed it to assume the column was a CHAR(10), and to print the actual value. I made a couple of other changes to two of the other printBrief methods to get better line breaks in the output.

Next I ran the test without partitioning. I got a very simple MDAM network which was easy to see is correct.

Next I ran the test that fails, followed by the test that succeeds. See the two attachments for the MDAM networks of each. 

----- NOTE from HZ: This is the description of the bug reported here

It turns out that both trees are bad, and they are bad in the same way. However, the failing tree has real partitioning key values in it and happens to partition the ESPs right on an existing key value (as Ravisha had discovered by other means). The succeeding tree has a weird partitioning key values (‘<region b, the quote is part of the data), and so divides the work among the ESPs on boundaries that don’t exist in the data. 

To verify this, I inserted this row:

>>insert into new_t1 values 
+> ('''<region b','''<region b','''<region b',' ',' ',' ',' ');

--- 1 row(s) inserted.

I then ran both the failing and the ‘succeeding’ queries. Now, the first one fails as it did before, with the row 52, bb2, c duplicated. The ‘succeeding’ query now fails, with the row ‘< region b, ‘<region b, ‘<region b showing up three times!

There are apparently two bugs operating here.

One bug is that incorrect partition boundaries are supplied the second time the query is prepared and executed. This is the opposite of an uninitialized variable problem: Something has been cached somewhere and gets processed incorrectly!

The other bug seems to be that the partitioning function ANDed into the MDAM tree is incorrect. It appears to be a predicate of the form *partition-boundary-1* <= c1, c2, c3 <= *partition-boundary-2*.  The second “<=” should be “<”, except for the last partition.

In the very old days, I remember adding a special ItemExpr to handle these funny “<” or “<=” on the last partition predicates. It may be that this ItemExpr is being incorrectly processed when we build the Mdam Network. That is the next avenue of investigation.

Dave



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)