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
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: A B
• Reporter: A B
• Component/s: SQL
• Affects Version/s: 10.3.1.4
• Fix Version/s: 10.3.1.4

Description

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).

Comments

[A B]

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...

[A B]

derbyall and suites.All ran cleanly on SUSE Linux with ibm142, so I committed the changes with svn # 547066:

  URL: http://svn.apache.org/viewvc?view=rev&rev=547066

Marking this issue as resolved. If there are any suggestions about how to make the code comments and/or relevant method names more clear, I can address those in a subsequent patch. Otherwise I think this issue is complete.