Resolved Issues

Depending on the locale, the fractional separators can differ. This locale dependency could have caused error messages such as "Invalid duration: 0.xxs: invalid unit". (14743)

Executing a CREATE TABLE statement that defined a case-sensitive self-referencing foreign key within the same statement could have reported an internal error. (14982)

During startup, the message "Failed to write system dependencies: string pointer is null" was logged incorrectly. (15074)

EXPLAIN plans reported in QUERYSTATS were incomplete for SQL queries that used parallel execution. (15067)

SQL queries that perform outer joins that contain explicit JOIN could have taken longer compared to those that have join conditions in the WHERE clause. (15015, 14468)

SQL queries that included RAND() and UUID() returned inaccurate results due to unintended or duplicate evaluations caused by optimizer rewrites. (14941)

A SQL SELECT query processing timestamps that included fractional seconds before the Unix Epoch (January 1, 1970, 00:00:00 UTC) could have returned inaccurate results. (14588)

A SQL query that included a filter applied on a CASE clause containing attributes used in the join condition of an outer join returned an inaccurate result. (15144)

A SQL query that includes a JOIN in the FROM clause could have unexpectedly resulted in an updatable view.

A SQL query that included correlated subqueries with an outer join reported an INTERNAL_ERROR.

A SQL query that included TYPEOF() for a value of type 'bytes' returned a type and length information. Bytes is a potentially unlimited binary type, which is not expected to have a length information. Hence, reporting the length information was not expected.

A SQL query that uses existential Right Hash Joins could have returned inaccurate results.

A SQL query that included STDDEV_SAMP(), STDDEV_POP(), VAR_SAMP(), or VAR_POP() functions that operate on large BIGINT values returned an error.

A SQL query with existential joins and correlated subqueries returned inaccurate results in the presence of nulls.

A SQL ANALYZE TABLE operation could have stopped unexpectedly if an index change occurred concurrently.

Temporary tables created using CREATE TEMP|TEMPORARY TABLE <table name> ON COMMIT DROP persisted after ending the transaction using ROLLBACK, instead of getting deleted.

When a new column was added to a table created using CREATE TABLE LIKE, the column was added in an unexpected position.

When the always-recompile-queries connection property was enabled, the results of a SQL query executed using EXPLAIN (ANALYZE ON) and the results in the LASTSTATEMENT system table could have been inaccurate.

When the isolation level was set to CONSISTENT READ, adding a NOT NULL column with a default value using ALTER TABLE could have set the column to NULL instead of the default value in rows added by a transaction that was active when ALTER TABLE is executed.

When casting from Binary to String, UTF-8 validity check was not enforced, which could result in invalid string.

The DBA role showed trigger grant privileges even after the support for triggers on system tables was removed.

Journal recovery did not trigger garbage collection when the configured memory limit was smaller than the allocated memory.

Accessing a deleted object while running garbage collection could have caused the Transaction Engine (TE) to shut down unexpectedly.

The INDEXHITS field in LASTPARALLELSTATEMENT and LASTSTATEMENT system tables could have reported inaccurate results.

If a database archive restore operation did not complete successfully in containerized deployments, retries were prevented because the archive metadata file (info.json) was missing.

If, in a single transaction, a row R was locked using SELECT …​ FOR UPDATE before savepoint S, and R was updated or deleted after S, then rolling back to S would release the lock on R.

A row lock acquired using SELECT …​ FOR UPDATE could have been released if an UPDATE or DELETE that modified a locked row threw an exception.

The DATA_BUFFERING_MB field in the QUERYBUFFERSTATS system table reported inaccurate results when query operators used hash tables to perform joins or grouping operations.

The STARTID field in the QUERYSTATS system table reported inaccurate results.

Tab completion in nuocmd was unavailable when using the NuoDB client drivers or Docker image.

In rare cases, during archive synchronization, the syncing Storage Manager (SM) could have shut down unexpectedly with, "no more SMs are SYNCing but some of them died".

In rare cases, streaming index scans were not treated as covering scans, even when the index contained all columns required by the query.

In rare cases, a SQL query could have terminated unexpectedly reporting undefined references error.

In rare cases, SQL queries that fetched partitioned table statistics returned an internal error if a partition was dropped.

For partitioned tables, skewed data was not detected correctly which prevented the re-optimization of parameterized queries. (15054)

After adding a storage group, the SM could have shut down unexpectedly due to a segmentation fault while processing BTREE index changes. (14976)

The EXPLAIN field in the QUERYSTATS system table could have been empty for SELECT statements and DML statements including INSERT, UPDATE, or DELETE. (15067)

Executing SQL SELECT queries with a LIMIT NULL or OFFSET NULL clause caused the TE to shut down unexpectedly. (15086)
Now the LIMIT or OFFSET clause is ignored when it is set to NULL.

When additional SMs were added to a database that was started with one SM per storage group, one of the SMs could have exited during synchronization with a message similar to, "EXITED(MONITORED:SYNCING):EXIT: SYNC: 108: Not syncing xxx because no other SMs serve storage group xx".

When SQL insert statements were executed on a partitioned table using the batch processing API, the associated Transaction Engine (TE) could have shut down unexpectedly.

In rare cases, a Storage Manager (SM) could have shut down unexpectedly reporting, "unable to free memory for 5m" after large tables were dropped. (14879, 15011, 15017, 15018)

A SQL query that used disjunction (OR) in semi joins could have taken longer to execute than in previous NuoDB versions. For example, "SELECT f1 FROM t1 WHERE f2 IN (SELECT …​ FROM …​) OR f2 IN (SELECT …​ FROM …​);". (13962)

Querying metadata concurrently with creating a MERGE TREE index could have caused the TE processing those commands to shut down unexpectedly.

In systems experiencing high load with network partitions and slow I/O, failure resolution could restart repeatedly and might not have completed because it was waiting for failover to complete. (14099, 14275, 14276, 14312, 14555, 14938, 15058, 15098)

After executing DML statements that requested generated keys, the database could have reported an invalid transaction ID in logs and pseudo tables.

Merge tree index read performance optimizations could have increased occurrences of the error "Unable to verify uniqueness in index "XXX" after 10 attempts".

In rare cases, heavy concurrent upload or rollback workloads could have caused duplicate keys to be inserted into a unique multi-index, causing a unique multi-index constraint violation.

When executing INSERT ON DUPLICATE KEY UPDATE, the statement update count was not updated accurately if a duplicate key was detected. (14864)

In rare cases, when a query that requested an atom from another node was executed concurrently with ALTER TABLE ADD PARTITION or ALTER TABLE MODIFY PARTITION, the communication between the nodes could have stalled, causing some queries to hang.

In rare cases, execution of a SQL query that uses a UNION operation inside JOINs and includes conflicting predicates could have caused the TE or SM to shut down unexpectedly. (14947)

When using Optimizer v3, SQL queries that perform a JOIN operation on the results of a UNION operation could have taken longer to execute. (14850)

The STARTID field in the CONNECTIONS system table could have contained -1 instead of the correct start ID of the Transaction Engines (TEs).

In rare cases, archive synchronization could have run indefinitely while the log reports 0 catalogs remaining to sync.

Execution of SQL queries that include a HAVING clause on a group key could have returned inaccurate results.

Repeated execution of SQL queries that use index scans could have taken longer because the state of index scans was not reused.

Execution of a SQL query that included 64 tables or 63 joins could have reported "Internal error: failed precondition _plan.expression(p).referencedRelations().is_subset_of(available), file xxx".

Parameterized SQL queries that included LIKE, STARTING, or ESCAPE with a NULL parameter could have reported "Cannot convert <null> into string". (14774)

A SQL UPDATE statement with a JOIN clause could have resulted in error because update checks were also performed on joined views which are not updatable.

Execution of SQL queries with dependent right outer join operations could have returned inaccurate results.

SQL queries with dependent joins could have taken longer to execute because of the suboptimal execution plan chosen by the optimizer.

When a SQL statement resulted in duplicate keys error on a unique index containing BINARY, VARBINARY, or BYTES columns, the error message could have included unreadable key values or misleading information related to decoding values. (14756)

When the KEY_ORDERED optimizer hint was specified in a SQL query, the hint was ignored if the optimizer elected to use Parallel query execution.
The optimizer now prioritizes the KEY_ORDERED hint over Parallel query execution.

Execution of SQL queries with correlated subqueries and non-inner joins could have terminated and report a precondition error.

A SQL query that uses decorrelated dependent existential Right Hash Joins could have returned inaccurate results when NULL values were included in the existential comparison.

A SQL query that included multiple join operations, with at least one dependent join and a LIMIT clause, could have returned inaccurate results.

Execution of SQL statements with multiple Common Table Expressions (CTEs) defined with the same name in the same scope of a SQL query used only the first definition, and all the subsequent definitions were ignored without any warning.
Now the execution of such statements are blocked and an error message is reported. For more information, see WITH.

When using nuosql, executing user-defined stored procedures with EXECUTE could have returned results without column names.

Executing any SELECT query from GETSTATSMETADATA () on a pseudo table could have reported a precondition error instead of raising an exception.

Executing a SQL query that performed hash join operations between string expressions of different data types could have reported inaccurate results.

Executing a SQL query on a temporary table created from an existing partitioned table using CREATE TABLE LIKE could have caused the database to shut down unexpectedly.

A SQL query that included a precision parameter in the CURRENT_TIMESTAMP function could have reported an error. (14473)

In rare cases, when parallel query execution was enabled, a TE could have shut down unexpectedly reporting "ASSERT : Platform/PlatformTransaction.cpp:xx: FAILED: op". (14948, 15075, 15195)

A SQL query that included a precision parameter in the CURRENT_TIME function could have returned inaccurate results. (14473)

A SQL query that compared the result of CURRENT TIME or CURRENT TIMESTAMP with a TIME literal could have returned inaccurate results. (14575)

A SQL query that included a parameter that was cast to a specific data type could have returned inaccurate results because the data type length was ignored after casting.

A SQL query that included a GROUP BY clause with only constant values and an ORDER BY clause could have caused the TE to shut down unexpectedly.

A SQL query could have reported inaccurate results when using the hash variants of right outer, full outer, or right existential join operators on columns that contained NULL values.

A SQL query that used decorrelated dependent existential hash joins could have returned inaccurate results when NULL values were included in the existential comparison.

Executing a CREATE TABLE SQL statement with column names beginning with HELP could have resulted in a syntax error.

Executing an ANALYZE SQL statement containing projections could have reported inaccurate statistics because only the accumulated number of rows of multiple executions were reported (without providing the average over all executions).

If the parameters accessed by a pseudo table were modified during query execution, the TE could have reported an error.

When using the nuosql command line tool, recalling previous commands using ! commands could have reported an error.

Executing nuoloader with the --export option without specifying a CSV file name could have resulted in unexpected behavior. (14695)

When using C, C++, or Java drivers, the IS_GENERATEDCOLUMN field in the DatabaseMetaData object returned by getMetaData() could have contained the value NO for columns defined as GENERATED BY DEFAULT.
Now the IS_GENERATEDCOLUMN field correctly returns a YES for columns defined as GENERATED BY DEFAULT.

Large Object (LOB) data could have been processed using the hardcoded chunk size of 1024 bytes and the default chunk size of 65536 bytes was ignored. (13739)

Building a very large index using MERGE TREE, could have caused the Transaction Engine (TE) to shut down unexpectedly. (14699)

A transaction executing a DDL operation could have automatically rolled back if an exception occurred due to an update conflict with another transaction.

In rare cases, a SQL query could have returned inaccurate results due to a race condition between garbage collection and index scan.

In rare cases, a SQL query could have reported "result set unusable (corrupted record must be removed)" even though no corruption occurred.

In rare cases, MERGE TREE index statistics were not updated after removing all the data from a table.

In rare cases, an object fetch operation would not be fully acknowledged by another node, causing database operations involving that object to wait indefinitely.

In rare cases, a Transaction Engine (TE) shut down unexpectedly when executing a SQL query that included a UNION operator. (14666)

Index statistics generation was not triggered when creating or rebuilding an index. This affected offline builds of tables with records that span multiple atoms.

The Table Statistics (Stats v3) metadata was not updated automatically for system tables.

A SQL query that included predicates in a correlated subquery referencing literals from another subquery could have reported "Error 58000: Internal error: failed precondition hasValidUnfilteredCardinality(relationId)". (14684)

When using the v3 optimizer, a SQL query could have taken longer to execute because the optimizer might not select the most efficient index while executing the query.

When the stats-v2-collection database option was disabled, automatic v2 statistics updates were not completely disabled, causing inaccuracies in cardinality estimates and resulting in slow query performance. (14668, 14748)

A SQL query that executed the RAND() function a large number of times could have generated more duplicate values than expected. (14512)

If LOB streaming was enabled by configuring the lobChunkingEnabled connection property to true in the NuoDB JDBC driver, a SQL query that fetches multiple BLOBs or CLOBs could have caused a Transaction Engine (TE) to shut down with "Unable to free memory for 300 seconds".

Using nuodump with the output-schema option failed to replace schema references within foreign key constraints with the specified output schema.

Executing the EXPLAIN query on a SQL statement that included columns with case insensitive collation could have returned inaccurate results.

If a table was converted to a partitioned table, running a SQL query against the table could have caused the executing TE to shut down unexpectedly.

A SQL query that included an ATAN2() function could have returned inaccurate results. (14538)

A newly started Storage Manager (SM) with an archive of type LSA that attempted to synchronize with an existing SM while running a write-heavy workload could have shut down unexpectedly with, "Archive failure: 'write' failed with error No space left on device".

In rare cases, if an SM shut down soon after the database had made changes to an atom that was not previously in memory, the copy of the atom in the SM’s archive could have become corrupted.

Write-heavy workloads (workloads that include DML statements) could have taken longer to execute due to the logging of non-cached user queries.

The log files could be named incorrectly when using nuocmd get log-messages or nuocmd show log-messages with the --engine-file option.

A synchronizing SM could have shut down unexpectedly with "FAILED: BUGCHECK: Type of object xx/yy is unknown" because an object was deleted.

If index statistics were requested during the shutdown of a TE or an SM, during the execution of the DROP INDEX statement, or when rebuilding indexes for a table, a SQL ANALYZE TABLE statement could have run indefinitely.
This could have also prevented the automatic update of statistics.