[
https://issues.apache.org/jira/browse/TRAFODION-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553148#comment-16553148
]
ASF GitHub Bot commented on TRAFODION-3158:
-------------------------------------------
GitHub user DaveBirdsall opened a pull request:
https://github.com/apache/trafodion/pull/1660
[TRAFODION-3158] Make EncodedValue error handling more robust
This pull request makes two code changes to function
EncodedValue::constructorFunction.
1. Formerly, the function would check for the existence of an error in
CmpCommon::diags() and remove it if present. This wasn't sufficient though as
the test case in the JIRA generated *two* errors in CmpCommon::diags(); the
code as it was removed only one of them. The result was that the Normalizer
retried the query, and the warnings concerning the bad histogram values were
lost.
2. In my initial attempt to fix this problem, I put an unguarded call to
CmpCommon::diags()->mark() to capture the state of CmpCommon::diags() on entry
to EncodedValue::constructorFunction. This turned out to cause cores in the
mxssmp process at sqstart time, because in that process it happened that the
EncodedValue constructor for a global object was called before the global
CmpCommon::diags() was initialized. This could have happened in any process;
it's just the luck of the draw in what order the linker decides to invoke
global constructors. So to fix that problem, I was forced to add a flag so that
code paths involving global objects do not try to dereference
CmpCommon::diags(). This change is to my mind ugly; I added extensive comments
explaining the situation. Some significant refactoring will be required to
produce a more elegant solution.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/DaveBirdsall/trafodion Trafodion3158
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafodion/pull/1660.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1660
----
commit 64e5ed11a2d1deae8d748d7d749abb5007ae0c41
Author: Dave Birdsall <dbirdsall@...>
Date: 2018-07-23T17:24:57Z
[TRAFODION-3158] Make EncodedValue error handling more robust
----
> Bad histogram values are sometimes not reported
> -----------------------------------------------
>
> Key: TRAFODION-3158
> URL: https://issues.apache.org/jira/browse/TRAFODION-3158
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Affects Versions: 2.3
> Reporter: David Wayne Birdsall
> Assignee: David Wayne Birdsall
> Priority: Major
>
> Function EncodedValue::constructorFunction has logic to raise a 6003 warning
> if it encounters invalid values in histogram intervals. When this happens,
> the compiler generates a default histogram for that column (that is, it
> behaves as if it has no statistics for that column.) This can lead to poor
> query plans. In some circumstances, however, this warning does not get
> reported, so the user is not aware of the possible compromise in plan quality.
> An example of this can be created as follows:
> # Create a Hive table Test1 with columns (a int, b int). Put some data into
> it, and in Trafodion, use UPDATE STATISTICS FOR TABLE HIVE.HIVE.TEST1 to
> generate statistics for it.
> # Outside of Trafodion (in the Hive shell, say), drop and recreate the Hive
> table, but this time with columns (a string, b string). Populate that with a
> few rows.
> # In a fresh sqlci session, do "prepare s1 from select a,b from
> hive.hive.test1 where a < 'abcd';". This will appear to be successful,
> however in fact 6003 warnings were generated internally but not reported.
> Another way to create an example is to create a Trafodion table, test1, with
> columns (a char(4), b char(4). Put some rows into it and do UPDATE STATISTICS
> on it. Then manually alter the boundary value in one of the
> SB_HISTOGRAM_INTERVALS tables, changing a value from a character string
> literal to a numeric literal. For example, change "('abcd')" to "(3)".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
