[
https://issues.apache.org/jira/browse/TRAFODION-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan resolved TRAFODION-926.
-------------------------------------------------
Resolution: Duplicate
This issue has been addressed as part of enhancing bulk load in Trafodon. See
https://issues.apache.org/jira/browse/TRAFODION-2351?filter=-3
> 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: [email protected]
> Assignee: Selvaganesan Govindarajan
> Fix For: 2.1-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.15#6346)
