Resolved Issues

This section includes fixes that do not change the user interface and/or API behavior of the product. For a summary of changes, see Changes in this release.

If a resolution is associated with a reported issue, a Zendesk reference number is displayed, for example (10283).

Resolved in NuoDB 6.0.2

  • SQL insert operations into a table with a non-unique Merge Tree index could be blocked indefinitely. (14145)
    The issue has been resolved.

  • An INSERT INTO statement that includes VALUES and DUPLICATE KEY with scalar subqueries within the VALUES clause could report "Error 58000: Internal error: failed precondition expressionId != INVALID_ID". (14085)
    The issue has been resolved.

  • When NuoDB was deployed on a Linux ARM64 platform, the core files were larger in size and took longer to dump, compress, and copy.
    The issue has been resolved.

  • When using a container-runtime environment other than Docker (For example, Containerd), the container ID was not recorded correctly.
    The issue has been resolved.

  • In some cases, when a SQL query included an ORDERED hint and an ORDER BY clause, the optimizer could ignore the hint.
    The issue has been resolved.

  • When using the REOPTIMIZE HINT NEVER hint, a SQL query that includes a comparison predicate that compares a partition column with a user parameter could take longer to execute.
    The issue has been resolved.

  • When a SELECT FOR UPDATE NOWAIT statement was executed on a locked table, the statement would wait for the lock to be released.
    The issue has been resolved.

  • The NuoAdmin REST API request GET /api/1/peers/<server_ID> with a non-existent server_ID could generate a response in HTML format instead of JSON. (14046)
    The issue has been resolved.

  • A memory fragmentation problem when using index keys with varying sizes could cause the database processes to shut down unexpectedly with "BUGCHECK: Unable to free memory for 300 seconds". (13676, 14095)
    The issue has been resolved.

  • After deleting indexes on a Storage Manager (SM), the SM could shut down unexpectedly during the synchronisation process with "ASSERT: Platform/PlatformCatalog.cpp:7315: FAILED: …​.".
    The issue has been resolved.

  • When a large number of write operations or data inserts occur, SMs could shut down unexpectedly with "Error::terminate". (13939)
    The issue has been resolved.

  • Executing nuoarchive check --dry-run on a repaired archive reported "FAILED: !expungeAll".
    The issue has been resolved.

  • Using parenthesis inconsistently in a partition statement was allowed.
    The issue has been resolved.

  • When nuocmd show domain is used during journal recovery, instead of reporting the archive update progress with "RECOVERING_JOURNAL:SAVE(nn%)", the SMs could report "CONFIGURED:RECOVERING_JOURNAL(100.0%)" until the recovery is complete. (13508)
    The issue has been resolved.

  • Executing a SQL statement with REPLACE INTO clause within a trigger could report, "Error 42000: syntax error".
    The issue has been resolved.

  • In Optimizer v3, when SQL queries containing both in-list and attribute-referencing predicates on the same join attribute of an outer join operation were executed, the Transaction Engine (TE) could shut down unexpectedly.
    The issue has been resolved.

Resolved in Previous NuoDB 5.1.x Releases

  • SQL queries could become unresponsive during and after archive synchronization due to aggressive message throttling. (14161, 14183, 14184,14186, 14189)
    The issue has been resolved.

  • Executing a SQL query with indexes with a high number of nulls could result in reduced performance due to incorrect index selection during the query optimization. (14180)
    The issue has been resolved.

  • After modifying the data in an indexed table, a SQL SELECT query with LIMIT and OFFSET on the indexed table could temporarily return inaccurate results.
    The issue has been resolved.

  • A SELECT DISTINCT query containing a JOIN operation on a table with a primary key or unique index could return non-distinct results.
    The issue has been resolved.

  • A SQL query that contains a SQL window function with timestamp columns in the ORDER BY clause or the PARTITION BY clause, could report "Unable to search a date column with a ref of type 8". (14158)
    The issue has been resolved.

  • A SQL query producing the result of an existential predicate and filtered based on the same predicate could return inaccurate results.
    The issue has been resolved.

  • In some cases, a Storage Manager (SM) could take longer than expected to perform archive sync and have reduced available cache space.
    The issue has been resolved.

  • Using the SQL command DROP to delete objects may cause unwanted changes to the contents of the journal and may fail to recover after the SM is stopped and then restarted.
    The issue has been resolved.

  • On a leap day, a SQL query that includes the DATE_TO_STR function with a missing date or time information could report "Could not parse <date string> with pattern <pattern>".
    The issue has been resolved.

  • In some cases, nuocmd get stats would report a too-large value for the ArchiveReadQueueMedium metric.
    The issue has been resolved.

  • When nuoarchive --restore was used to restore the archive to the last transaction using the Point-in-Time Restore method, the SMs could shut down unexpectedly with an Out-of-Memory (OOM) error. (13975)
    The issue has been resolved.

  • When nuocmd get stats was executed, the value of ArchiveSyncThrottleTime was reported in microseconds instead of milliseconds.
    The issue has been resolved.

  • In cases where Optimizer v3 selected to use the Right Hash Outer Join operator, the SQL statement could return inaccurate results.
    The issue has been resolved.

  • Optimizer v2 could return inaccurate results when window functions were used in a subquery that exported the same column twice with different names.
    The issue has been resolved.

  • In rare cases, an AP started with a valid NuoDB license could report, "Unable to verify license in <location>: License expired".
    The issue has been resolved.

  • The explain plan of a SQL statement could report inaccurate statistics for the atoms and rows when the corresponding counters have high values.
    The issue has been resolved.

  • Executing SQL statements containing the concatenation string operator (||) in conjunction with CAST could produce inaccurate results.
    The issue has been resolved.

  • When executing a SQL query with range predicates using indexes, if the scale of the boundaries is larger than the scale of the attributes in the table, the query could return inaccurate results.
    The issue has been resolved.

  • When executing a SQL statement with an ORDER BY clause on an expression alias, the query could produce results that are not in the correct order.
    The issue has been resolved.

  • A SQL query that displayed the QUERYSTATS system table, could report inaccurate counters and timer data in the EXPLAIN output.
    The issue has been resolved.

  • The execution of a SQL query that contained a constant equality predicate on a column that was also used in an order by, group by, or window clause, could take longer than expected. (13933)
    The issue has been resolved.

  • When using the READ_COMMITED isolation level and executing multiple SQL statements of type INSERT or TRUNCATE on the same table, statements could abort due to stale locks with the error message, "error: failed precondition tries > 0".
    The issue has been resolved.

  • Issues resolved in Optimizer v3

    • A SQL query that includes an ORDER BY clause and a predicate containing multiple references of the column used in the ORDER BY clause could return results in incorrect order.

    • A SQL query could take longer to execute if a large portion of an index contains the same value. (13883)

    • In some cases, a SQL query that includes a not equal predicate, an existential predicate, and an index that has its first field used in the not equal predicate and the second field in the existential predicate could report "Error 58000: Internal error: failed precondition batchScan". (14044)

    • Execution of SQL statements on a new table, where statistics have not been fully collected, could take longer due to the full table scan used by the optimizer. (13915)

    • Execution of EXPLAIN with the ANALYZE ON parameter on a SQL statement may report "Error 58000: invalid UTF-8 code sequence". (13962)

    • Execution of SQL queries with existential subqueries using [NOT] EXISTS or [NOT] IN (SELECT …​) could take longer to execute when using Optimizer v3. (13974)

    • SQL queries with complex filtering conditions and multiple table joins could take longer to execute when using Optimizer v3. (13971)

    • The Right Index Semi Join operator did not support composite bitmap scans, Bitmap And and Bitmap Or. (13955)

    • SQL queries that include a partitioned table in an OUTER JOIN could sometimes take longer to execute. (14002)

    • A SQL query that includes predicates with a non-boolean return type could produce inaccurate results.

    • When executing a SQL query with scalar subqueries as parameters of a table function, the order in which the parameters of the table function are considered could be inaccurate producing inaccurate results.

    • Executing a SQL query with scalar subqueries could result in reduced performance. The explain plans could report inaccurate cost estimates for joins with scalar subqueries. (13893)

    • When the optimizer generates an execution plan to access data in partitioned tables, the Transaction Engine (TE) could shut down unexpectedly.

    • A parameterized SQL query could take longer to execute due to the less optimal execution plan selected by the optimizer. (13919, 14013)

    • Executing a SQL statement containing the APPROX_COUNT_DISTINCT clause and the GROUP BY clause could report inaccurate results.

    • SQL statements that result in pushing multiple IN lists to a single index access may not explore the entire search space of index access paths and could result in longer processing time. (13910)

    • Executing EXPLAIN (ANALYZE ON) on SQL statements with a Left outer hash join could return inaccurate timing results.

    • In some cases the system may leak memory, which could cause a slowdown due to the reduction in the amount of memory available to cache the working data set. (14069)

    These issues have been resolved.