You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "Suresh Subbiah (JIRA)" <ji...@apache.org> on 2015/10/08 07:12:26 UTC
[jira] [Assigned] (TRAFODION-926) LP Bug: 1413400 - HDFS scan
operator may not always return diags info with error entry
[ https://issues.apache.org/jira/browse/TRAFODION-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Subbiah reassigned TRAFODION-926:
----------------------------------------
Assignee: Selvaganesan Govindarajan (was: justin.du@hp.com)
> LP Bug: 1413400 - HDFS scan operator may not always return diags info with error entry
> --------------------------------------------------------------------------------------
>
> Key: TRAFODION-926
> URL: https://issues.apache.org/jira/browse/TRAFODION-926
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
> Reporter: justin.du@hp.com
> Assignee: Selvaganesan Govindarajan
> Fix For: 2.0-incubating
>
>
> This problem was found when examining the esp core files. The code dump was due to the reason at these lines in sql/executor/ex_tuple_flow.cpp:
> 349 ComDiagsArea * da = src_entry->getDiagsArea();
> 350 ex_assert(da, "We have a Q_SQLERROR in Tupleflow but no diags area");
> 351
> Further analysis indicates that ExHdfsScanTcb::work() method inserted the Q_SQLERROR entry to its parent up queue without attaching the diags area with it.
> When the work method inserts a Q_SQLERROR entry, it expects that the head entry of the parent down queue contains the diags area, which was populated in other steps prior to the HANDLE_ERROR step, or the workAtp_ should have one. Otherwise, it could return that entry without populated the atp_ diags area of the entry.
> The more suspicious area is at line 820 of sql/executor/ExHdfsScan.cpp when ExHdfsScanTcb::extractAndTransformAsciiSourceToSqlRow() call returns error but without populating the diagsArea of workAtp_.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)