[
https://issues.apache.org/jira/browse/DERBY-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-2805:
-----------------------
Attachment: d2805_v1.stat
d2805_v1.patch
Attaching d2805_v1.patch to address this issue. Patch does the following:
1 - Renames the "markOrderingDependent()" method and related variables to
reflect their use: which is, so far as I can tell, to indicate that
the optimizer has eliminated a sort and thus that the underlying
result sets *may* need to make adjustments to compensate for the
dropped sort. At the moment the only result set node which needs
to make such an adjustment is IndexRowToBaseRowNode.
2 - Updates comments where appropriate to more explicitly describe the
intended use of the new "adjustForSortElimination()" method
(which is what "markOrderingDependent()" was renamed to).
3 - Adds a void implementation of "adjustForSortElimination()" to the
FromVTI class since that class doesn't need to make any adjustments.
This void method is what solves the failure reported in this issue.
4 - Adds appropriate test cases to a new fixture in the existing
lang/SysDiagVTIMappingTest JUnit test.
Note that this patch touches several files due the method renaming mentioned in
#1.
I'm running derbyall and suites.All now and will post when they are done. In
the meantime, it would be great if someone could review the renaming and
associated comments to see if they do in fact make things clearer; if not,
perhaps I can give it another go before committing...
> ASSERT failure with sane build if DISTINCT and ORDER BY are present in a
> query that selects from a diagnostic table function.
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2805
> URL: https://issues.apache.org/jira/browse/DERBY-2805
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.0.0
> Reporter: A B
> Assignee: A B
> Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: d2805_v1.patch, d2805_v1.stat
>
>
> Attempts to execute the following query will lead to an ASSERT failure with
> sane jars:
> ij> select distinct * from table(syscs_diag.space_table('T1')) X order by 3;
> ERROR XJ001: Java exception: 'ASSERT FAILED markOrderingDependent() not
> expected to be called for org.apache.derby.impl.sql.compile.FromVTI:
> org.apache.derby.shared.common.sanity.AssertFailure'.
> Stack trace is:
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> at ResultSetNode.markOrderingDependent(ResultSetNode.java:1881)
> at
> SingleChildResultSetNode.markOrderingDependent(SingleChildResultSetNode.java:578)
> at
> SingleChildResultSetNode.markOrderingDependent(SingleChildResultSetNode.java:578)
> at
> SingleChildResultSetNode.markOrderingDependent(SingleChildResultSetNode.java:578)
> at SelectNode.genProjectRestrict(SelectNode.java:1409)
> at SelectNode.modifyAccessPaths(SelectNode.java:1816)
> at
> SingleChildResultSetNode.modifyAccessPaths(SingleChildResultSetNode.java:439)
> at DMLStatementNode.optimizeStatement(DMLStatementNode.java:307)
> at CursorNode.optimizeStatement(CursorNode.java:515)
> I was able to avoid this by adding an empty implementation of
> "markOrderingDependent" to the FromVTI class, so that's probably the fix that
> I will post (after looking a bit more closely at the code to see if this
> makes sense).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
