You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by la...@apache.org on 2021/06/24 15:45:50 UTC

[impala] branch master updated: IMPALA-9763: builtin functions throw unknown exception

This is an automated email from the ASF dual-hosted git repository.

laszlog pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/impala.git


The following commit(s) were added to refs/heads/master by this push:
     new 9b75073  IMPALA-9763: builtin functions throw unknown exception
9b75073 is described below

commit 9b7507390dd7259be5b2319a022899989036df41
Author: liuyao <54...@163.com>
AuthorDate: Sat Jun 19 19:22:09 2021 +0800

    IMPALA-9763: builtin functions throw unknown exception
    
    There is a read-write contention in FunctionName#analyze()
    when a FunctionName object is shared to two threads: check if there
    is a builtin function in wrong database, when 'db_' is temporarily
    modified by the other thread.
    
    This patch fix this issue. For analyze FunctionName, if no database is
    specified, check builtinDb first; if FunctionName is not in builtinDb,
    set the database to defaultDb.Avoid setting the database of
    FunctionName to a temporary value
    
    Detailed description:
    
    This problem is caused by shallow copies. In the function
    FromClause::analyze(Analyzer analyzer), if the table is FeView,
    the analyzer will clone SelectStmt from the view's MetaData,
    which should be a deep copy. But in the copy constructor of
    FunctionCallExpr, fnName_ = other.fnName_, this is a shallow copy,
    which makes the fnName_ of multiple queries refer to the same block of
    memory. When the query is analyzed, the database of fnName_ will be
    set.But this will change the fnName_ of other queries.
    
    For example:
    
    create view1 as select coalesce(col1, 2) from table1;
    
    User A and User B check the same view1 at the same time. When
    user A’s query is analyzed, it runs to db_ = analyzer.getDefaultDb() of
    FunctionName::analyze. User B’s query is also analyzed and runs to
    FunctionCallExpr::analyzeImpl, and just completed FunctionName::analyze
    at this time, the step of user A's db_ = analyzer.getDefaultDb() will
    change the db_ attribute of user B's fnName_ to defaultDb, and then
    user B will continue to check whether the function is defaultDb,
    Throw an exception: coalesce() unknown for database .......
    
    Change-Id: Ifd77f5a7cd9a674340770233fe26eb5dc26e666a
    Reviewed-on: http://gerrit.cloudera.org:8080/17604
    Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
    Tested-by: Impala Public Jenkins <im...@cloudera.com>
---
 fe/src/main/java/org/apache/impala/analysis/FunctionName.java | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fe/src/main/java/org/apache/impala/analysis/FunctionName.java b/fe/src/main/java/org/apache/impala/analysis/FunctionName.java
index f3b3d5d..288f7cb 100644
--- a/fe/src/main/java/org/apache/impala/analysis/FunctionName.java
+++ b/fe/src/main/java/org/apache/impala/analysis/FunctionName.java
@@ -121,9 +121,10 @@ public class FunctionName {
     // Resolve the database for this function.
     Db builtinDb = BuiltinsDb.getInstance();
     if (!isFullyQualified()) {
-      db_ = analyzer.getDefaultDb();
       if (preferBuiltinsDb && builtinDb.containsFunction(fn_)) {
         db_ = BuiltinsDb.NAME;
+      } else {
+        db_ = analyzer.getDefaultDb();
       }
     }
     Preconditions.checkNotNull(db_);