[JBoss JIRA] Created: (TEIID-1676) Decomposed aggregates results can be wrong
by Steven Hawkins (JIRA)
Decomposed aggregates results can be wrong
------------------------------------------
Key: TEIID-1676
URL: https://issues.jboss.org/browse/TEIID-1676
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 7.4.1, 7.5
Decomposed aggregates results can be wrong when a cardinality dependent aggregate is computed against one side of a join and the other has a grouping pushed - and the staging grouping cols remove meaningful duplicate join results.
See TestAggregateProcessing.testJira1621 for an example of this situation. The current expected results are wrong.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (TEIID-1737) Error: Temporary table does not exist when using WITH clause and SQL Server
by Mark Brocato (JIRA)
Error: Temporary table does not exist when using WITH clause and SQL Server
---------------------------------------------------------------------------
Key: TEIID-1737
URL: https://issues.jboss.org/browse/TEIID-1737
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.5
Environment: JBoss AS 5.1, TEIID 7.5, SQL Server 2008
Reporter: Mark Brocato
Assignee: Steven Hawkins
It appears that the WITH clause is not compatible with SQL Server. The following simple query errors out:
with T1 as (
select id from DEMO.dbo.ACCESS_GROUP
)
select id from T1
The error message is: Remote org.teiid.api.exception.query.QueryProcessingException: Temporary table "T1" does not exist.
With Log4J debugging turned on I was able to do a little digging and it looks like to me that TEIID is sending the correct SQL down into SQL Server, but then gets confused when processing the result. Here is the relevant portion of the log:
12:56:29,910 DEBUG [COMMAND_LOG] START USER COMMAND: startTime=2011-08-31 12:56:29.91 requestID=QsxTHCTkSXXC.0 txID=null sessionID=QsxTHCTkSXXC applicationName=JDBC principal=user@teiid-security vdbName=Qiagram vdbVersion=1 sql=with T1 as (
select id from DEMO.dbo.ACCESS_GROUP
)
select id from T1
12:56:29,912 DEBUG [PROCESSOR] Request Thread QsxTHCTkSXXC.0 with state NEW
12:56:29,913 DEBUG [PROCESSOR] QsxTHCTkSXXC.0 No cache directive
12:56:29,913 DEBUG [PROCESSOR] QsxTHCTkSXXC.0 executing with T1 as (
select id from DEMO.dbo.ACCESS_GROUP
)
select id from T1
12:56:29,916 DEBUG [PROCESSOR] ProcessTree for QsxTHCTkSXXC.0 AccessNode(1) output=[id] WITH T1 (T1.id) AS (SELECT g_0.id FROM SCRAP.DEMO.dbo.ACCESS_GROUP AS g_0) SELECT g_0.id AS c_0 FROM T1 AS g_0
12:56:29,917 DEBUG [TXN_LOG] before getOrCreateTransactionContext:org.teiid.dqp.internal.process.TransactionServerImpl@1a53c407(QsxTHCTkSXXC)
12:56:29,917 DEBUG [TXN_LOG] after getOrCreateTransactionContext : QsxTHCTkSXXC NONE ID:NONE
12:56:29,917 DEBUG [BUFFER_MGR] Creating FileStore: 53
12:56:29,917 DEBUG [BUFFER_MGR] Creating TupleBuffer: 53 [id] [integer] of type PROCESSOR
12:56:29,918 DEBUG [PROCESSOR] QueryProcessor: closing processor
12:56:29,918 DEBUG [PROCESSOR] Request Thread QsxTHCTkSXXC.0 - error occurred
[QueryProcessingException]Temporary table "T1" does not exist.
at org.teiid.query.tempdata.TempTableStore.getOrCreateTempTable(TempTableStore.java:240)
at org.teiid.query.tempdata.TempTableDataManager.registerQuery(TempTableDataManager.java:487)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:188)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:176)
at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:358)
at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:156)
at org.teiid.query.processor.relational.RelationalPlan.open(RelationalPlan.java:153)
at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:182)
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:126)
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:352)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:278)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:207)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:194)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:118)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:288)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
12:56:29,923 DEBUG [COMMAND_LOG] ERROR USER COMMAND: endTime=2011-08-31 12:56:29.923 requestID=QsxTHCTkSXXC.0 txID=null sessionID=QsxTHCTkSXXC principal=user@teiid-security vdbName=Qiagram vdbVersion=1 finalRowCount=null
12:56:29,924 WARN [PROCESSOR] Processing exception 'Temporary table "T1" does not exist.' for request QsxTHCTkSXXC.0. Exception type org.teiid.api.exception.query.QueryProcessingException thrown from org.teiid.query.tempdata.TempTableStore.getOrCreateTempTable(TempTableStore.java:240). Enable more detailed logging to see the entire stacktrace.
12:56:29,924 DEBUG [PROCESSOR] Removing tuplesource for the request QsxTHCTkSXXC.0
12:56:29,924 DEBUG [BUFFER_MGR] Removing TupleBuffer: 53
12:56:29,924 DEBUG [PROCESSOR] Sending error to client QsxTHCTkSXXC.0
[QueryProcessingException]Temporary table "T1" does not exist.
at org.teiid.query.tempdata.TempTableStore.getOrCreateTempTable(TempTableStore.java:240)
at org.teiid.query.tempdata.TempTableDataManager.registerQuery(TempTableDataManager.java:487)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:188)
at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:176)
at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:358)
at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:156)
at org.teiid.query.processor.relational.RelationalPlan.open(RelationalPlan.java:153)
at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:182)
at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:126)
at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:352)
at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:278)
at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:207)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:194)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:118)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:288)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (TEIID-1758) Native PG Connector implement postgres DEALLOCATE command
by Graeme Gillies (JIRA)
Native PG Connector implement postgres DEALLOCATE command
---------------------------------------------------------
Key: TEIID-1758
URL: https://issues.jboss.org/browse/TEIID-1758
Project: Teiid
Issue Type: Bug
Affects Versions: 7.5
Environment: Teiid 7.5.0.Final using
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.8) (rhel-1.22.1.9.8.el5_6-x86_64)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
Running inside of JBoss EAP 5.1.1 on Red Hat Enterprise Linux Server release 5.7
problem occurs with perl-DBD-Pg versions 2.15.1-3.el6 and 2.18.0-2.fc15.i686 (and possibly others)
Reporter: Graeme Gillies
Assignee: Steven Hawkins
Hi,
We currently are using the below script to try and connect to our teiid instance and pull out a bunch of data. and we have noticed that the script works fine on Rhel5 (using perl-DBD-Pg-1.49-2.el5_3.1 for example) but does not work on newer OS's like Fedora 15 or Rhel6 (which have perl-DBD-Pg versions 2.15.1-3.el6 and 2.18.0-2.fc15.i686)
{code}
#!/usr/bin/env perl
use strict;
use warnings;
use DBI;
use DBD::Pg;
my $dbh = DBI->connect("dbi:Pg:dbname=EngVDBF;host=vdb.engineering.redhat.com;port=35432", 'teiid', 'teiid', {AutoCommit => 0})
|| die "Could not connect to database: $DBI::errstr";
my $ret = $dbh->selectall_hashref("SELECT MAX(Id) AS max_id FROM Rt4S.Transactions", 'max_id');
my ($result) = keys %$ret;
printf "selectall_hashref max_id = %8d\n", $result;
$ret = $dbh->selectrow_hashref("SELECT MAX(Id) AS max_id FROM Rt4S.Transactions");
printf "selectrow_hashref max_id = %8d\n", $ret->{max_id};
print "done!";
$dbh->disconnect();
{code}
The output we get when the script fails on newer systems is as follows
{noformat}
DBD::Pg::db selectall_hashref failed: ERROR: Parsing error: Encountered "DEALLOCATE" at line 1, column 1.
Was expecting one of:
"alter" ...
"call" ...
"create" ...
"delete" ...
"drop" ...
"exec" ...
"execute" ...
"insert" ...
"select" ...
"table" ...
...
DETAIL: org.teiid.jdbc.TeiidSQLException: Parsing error: Encountered "DEALLOCATE" at line 1, column 1.
Was expecting one of:
"alter" ...
"call" ...
"create" ...
"delete" ...
"drop" ...
"exec" ...
"execute" ...
"insert" ...
"select" ...
"table" ...
...
at ./teiid-fail.pl line 12.
selectall_hashref max_id = 2568235
DBD::Pg::db selectrow_hashref failed: ERROR: Parsing error: Encountered "DEALLOCATE" at line 1, column 1.
Was expecting one of:
"alter" ...
"call" ...
"create" ...
"delete" ...
"drop" ...
"exec" ...
"execute" ...
"insert" ...
"select" ...
"table" ...
...
DETAIL: org.teiid.jdbc.TeiidSQLException: Parsing error: Encountered "DEALLOCATE" at line 1, column 1.
Was expecting one of:
"alter" ...
"call" ...
"create" ...
"delete" ...
"drop" ...
"exec" ...
"execute" ...
"insert" ...
"select" ...
"table" ...
...
at ./teiid-fail.pl line 16.
selectrow_hashref max_id = 2568235
{noformat}
The output we get on RHEL5 is
{noformat}
selectall_hashref max_id = 2568235
selectrow_hashref max_id = 2568235
{noformat}
As you can see the query does run and is displayed correctly, but it looks like the Postgres driver sends a DEALLOCATE command to the server http://www.postgresql.org/docs/8.1/static/sql-deallocate.html which teiid doesn't know what it means so throws the error.
I tried to look in the DBD-Pg docs to see if I can get it to not call DEALLOCATE, but it looks like that might not be possible. Other languages postgres libraries might call the same command anyway.
Is it possible to have the DEALLOCATE statement implemented in teiid (even if it doesn't actually do anything) so that native libraries trying to call it won't throw these errors?
Regards,
Graeme
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (TEIID-1739) VDB deployment fails if metadata index file has been removed due to NPE during Index.initialize
by Larry O'Leary (JIRA)
VDB deployment fails if metadata index file has been removed due to NPE during Index.initialize
-----------------------------------------------------------------------------------------------
Key: TEIID-1739
URL: https://issues.jboss.org/browse/TEIID-1739
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 7.5
Reporter: Larry O'Leary
Assignee: Steven Hawkins
VDB couldn't be deployed, so customer restarted SOA-P server and the server.log shows:
DEPLOYMENTS MISSING DEPENDENCIES:
Deployment "VDBDeployer" is missing the following dependencies:
Dependency "SystemVDBDeployer" (should be in state "Create", but is actually in state "**ERROR**")
DEPLOYMENTS IN ERROR:
Deployment "SystemVDBDeployer" is in error due to the following reason(s): java.lang.NullPointerException, **ERROR**
ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Start: name=SystemVDBDeployer state=Create
java.lang.NullPointerException
at org.teiid.internal.core.index.BlocksIndexInput.close(BlocksIndexInput.java:65)
at org.teiid.internal.core.index.Index.initialize(Index.java:222)
at org.teiid.internal.core.index.Index.<init>(Index.java:82)
at org.teiid.metadata.index.IndexMetadataFactory.getMetadataStore(IndexMetadataFactory.java:119)
at org.teiid.deployers.SystemVDBDeployer.start(SystemVDBDeployer.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Although we do not yet know what has caused this situation, the NPE is a direct result of a bug in the way the index initialization is performed. In the event the file can not be read, we should simply remove the index entry but we don't get this far because when the file fails to be opened, we attempt to close it to ensure we cleanup our code. The problem is, the object was never initialized due to the file not being opened and therefore, we cause a NullPointerException:
Specifically, org.teiid.internal.core.index.BlocksIndexInput.close():
if (raf != null)
raf.close();
vraf.close();
should be something like:
if (raf != null)
raf.close();
if (vraf != null)
vraf.close();
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months