5.4.12 Yellowbrick Release Notes ​

An issue in the formula for common precision/scale of DECIMALS would make rendering of DECIMALs coming out of UNION ALL nodes use the wrong precision/scale.

Fix an issue where a semi join is converted into an unique inner join causing a distribution on the wrong columns, resulting in incorrect results.

Some backups could error out with: Abandoned due to client inactivity. This issue is rare and caused by a great number of backup chains in a single database that could delay the backup initialization phase.

Fix SMC issue that could cause it to stop working completely. Limit maximum number of rows returned for some queries in order to reduce memory requirements.

Improve replication cycle latency when transmitting large number of small tables.

CVE-2023-38408: The PKCS 11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system. (Code in /usr/lib is not necessarily safe for loading into ssh-agent.) NOTE this issue exists because of an incomplete fix for CVE-2016-10009.

datediff did not correctly implement the datepart boundary feature for the following dateparts: hour, minute, second, epoch, millisecond.

Allow pg_backend_pid() to be used in more contexts such as in queries containing:

current_database
current_schema
current_user
session_user
version

Previously, trying to use pg_backend_pid() with those functions would return:

ERROR: Function PG_BACKEND_PID is not supported

When the ybrelay client requested a commit, the ybrelay server did not wait to receive all of the data to be written to the database, especially when decompression of the data was time-consuming. The shutdown process has been improved so that all the data is committed.

Sometimes on a busy system, a query that produces a P0003: too many rows would error out with KE037: Something went wrong try again later.

Fix an issue where some complex queries wouldn’t fully utilise the query compilation cache requiring a round of query compilation per invocation.

Uniformize handling of negative exponents for non-integer types in the pow function. From this release, an error message such as a negative number raised to a non-integer power yields a complex result is expected as opposed to ‘NaN’.

TO_CHAR function call with a string casted to timestamp with time zone as argument would incorrectly return nothing.

In some rare instances, the sent_rows field in sys.log_unload would contain more rows than the actual number transmitted.

Outage caused by trickle inserts on wide table. The large number of NULL columns (decimal type) led to failures flushing the data to the column store.

Backup over SSL failed with "An unexpected exception occurred during ssl handshake on channel" due to connection timeout. New version of ybbackup tool, when used against this version of the YBD server, will retry more types of connection failure including SSL connection timeouts. This behaviour is enabled by default. Up to 3 retries per table are attempted (configurable).

• --retry-failed-backups: Enable retrying if a table fails to backup during the session. This option is only applicable to YDB instances that also support retrying.

• --retry-per-table-max: The maximum number of retry attempts for a single table before the program terminates with an error. Default: 3

Some types of correlated sub-queries could lead to DB front-end error. In some rare circumstances, it could cause a DB restart. Queries of this type will now error out with: "This form of correlated subquery is not supported"

System diagnostics is now faster on multi chassis systems.

DESCRIBE and EXPLAIN output of the CURRENT_DATE function changed in 5.4. It has been reverted to its prior behavior.

Implement limits for the evaluation of complex expressions in a single statement. Exceeding these limits will now result in a query error at compile time.

The Yellowbrick system doesn't enforce the limits by default, they can be set using the following GUC:

1. expression_complexity_limit
2. regex_count_limit - Total number of regular expressions that need to be compiled in a single query

The expression complexity limit is the depth of a single expression. The value is expressed in terms of the maximum number of evaluations that may be done at query execution time for each row for a single expression.

select <target list> from <table> where colN = 1 or colN = 2 or colN = 3;

The evaluation of the predicates for the query above has a complexity of 3.

select colA = 1 OR (colB = 2 AND colC = 3), colD = 2 OR (colE = 3 AND colF = 4) from <table> ...;

The evaluation of the expression for the query above has a complexity of 3.

Setting a expression complexity limit of 3 for the query:

select colA = 1 OR (colB = 2 AND colC = 3 AND colE = 4), colD = 2 OR (colE = 3 AND colF = 4) from <table> ...;

yields

ERROR: Expression too complex (expression complexity is 4). Reduce the number of columns or simplify the query

Evaluation of the IN operator for large lists are not affected by the expression_complexity_list, if and only if all elements of the list have the same type of are trivially converted.

For example:

select <target list> from <table> where colA IN (1, 2, /* 1000 elements */...);

succeeds even if the expression complexity limit is set to a low value like 3.

Setting the limits too low may result in failing to optimise queries that would have worked prior to this change.

Recommended values:

• regex_count_limit: 1000
• expression_complexity_limit: 5000

Please contact customer support for more information.

Cluster manager reconfiguration performance improvements following blade events.

Support for patch release rollback.

Use of LEFT(f() , N) or RIGHT(f(), N), N < 30 in a CTAS can cause system instability and possible outage.

The JSON_LOOKUP function returns a compile error when a NOT NULL constraint is defined on the column used for the first argument.

JSON_LOOKUP function doesn't handle key values of an empty string.

SMC "Configure > Users" generates the Error: PreparedStatementCallback; uncategorized SQLException...

The GETBIT function returned wrong results when used with BIGINT columns.

ybbackup backup bundle documentation update.

SELECT FROM sys.table_info could return ERROR: OID out of range if a TEMPORARY TABLE had rows in the user rowstore.

A CPU or Network saturated manager node could result in LDAP connections failing with Can't contact LDAP server. Connections will now be automatically retried.

The alert message for the catalog row store becoming full has been updated to help distinguish it from the user rowstore.

A lime restart could result in:

• some lime queries could fail with the error: KE032 Attempt to use spill space above limit
• the SMC "Worker CPU Utilization" and "Worker Memory Usage" dashboards not displaying current statistics the sys.log_query view not populated

A regression in Versions 5.4.8 and 5.4.9 caused some queries with Protegrity functions to return the following error:

ERROR: Assemble failed

A system restart caused by a race condition could occur for nested subqueries.

Use of the --log-level and --logfilelog-level ybrelay options were not reflected in the ybrelay logs.

Joining on strings where both string columns are larger (>30) but of differing lengths would return wrong results.

In stored procedures performing small inserts to the rowstore, all INSERT statements within BEGIN...EXCEPTION...END blocks were ignored until a new block was started or the end of the transaction was reached, causing data to be missing from the results of the full transaction.

Under certain circumstances, parity rebuild after a drive replacement would take longer than expected.

Running a query with multiple COALESCE columns would sometimes cause out of memory errors and a Postgres crash.

When output CHAR columns were not referenced consistently in the GROUP BY clause (with or without table qualifiers), the query returned the following error:

ERROR: variable not found in subplan target list

In some instances, a cursor fetch query in “client wait” state was not canceled during quiesce.

The number of distinct values was poorly estimated for scans with filters of the form: s

<column> = <constant>

These estimates have been improved in Version 5.4.8.

Prepared statements with typemod arguments that were executed with a generic plan produced wrong results.

A hung query in idle state was not present in the sys.query view and would not respond to yb_terminate_session or pg_termination_backend.

In Version 5.4.8, query cancellation has been improved for certain code paths in the planner.

Under certain conditions, running ybcli commands from the secondary manager node on the Andromeda platform would return the following error:

Can not retrieve this platform's hardware generation

Joining on strings where one string column is small (<=30) and the second string column is larger (>30) would return wrong results.

Default WLM restart rules were applied three times and for a large number of error codes. In Version 5.4.7, a smaller subset of error codes triggers a restart, and an attempted restart occurs only once per query.

A problem with the rewrite order involving CHAR data types would sometimes result in an internal error.

A query with multiple subqueries containing the concat(*) function caused a system crash when the query was run during planning.

Executing a stored procedure containing loops and an explicit exception statement would cause Postgres to crash if exception handling was involved.

A large number of SHOW statements referencing ybd_analyze_after_writes and ybd_analyze_after_loads were logged in sys.log_query, causing OOM and spill space errors. In Version 5.4.7, these statements are not logged.

In some instances, a NOT restriction of correlated subqueries was incorrectly applied, causing wrong results.

Cluster reconfiguration during a system restart could, in some rare cases, result in a deadlock because the self-healing mechanism could block indefinitely. In Version 5.4.7, the self-healing mechanism is more deterministic.

System view queries could return query text strings in GZIP-compressed format. In Version 5.4.7, these compressed strings are correctly decoded.

Joins on CHAR columns performed poorly because the planner added a redundant TRIM function for variable CHAR strings, which prevented bloom filters from being applied.

The third-party syslog-ng package was upgraded to fix a slow file descriptor leak. This leak occurred when the internal log files kept on each CMP were rotated, and triggered a DCS alert.

After an upgrade to Version 5.4.5, some queries required a lot more memory to run (or required more spill space and still ran out of memory).

A UNION ALL query that selected and constrained sequence values failed with the following error:

Generic UnexpectedException - Can't dlopen

The documentation was updated to clarify that SUBSTRING and SUBSTR are not equivalent functions. SUBSTRING returns a VARCHAR data type, but SUBSTR returns the data type of its input string.

After an upgrade to Version 5.4.5, the rewrite of LEFT joins with a NULL clause into an ANTI join caused a Postgres crash when the planner tried to access an uninitialized field from an unplanned subquery.

The Yellowbrick installer proceeded as far as the firmware upgrade step, then stopped progressing and failed to time out.

A distribution logic issue for SEMI LEFT joins caused redundant redistribution.

After setting a configuration parameter, using SET SESSION ROLE and SET LOCAL ROLE commands in succession within the same transaction caused a Postgres crash.

The IN-list rewrite optimization now works with all comparison operators. In previous releases, only the '=' and '<>' operators were supported for this optimization.

The --spark-sql application option did not accept a path that started with "file:". For example, calling spark-submit with the following syntax resulted in a "ParseException" error:

--spark-sql file:parquet.spark.sql

Rolling back a transaction with an active backup snapshot would sometimes cause a system crash.

A regression in Version 5.4.x caused some equality conditions on CHAR values with trailing spaces to return wrong results.

In some cases, the planner subquery estimation logic ignored casts. This behavior caused the wrong operators to be called and the database to shut down.

On the Andromeda platform, logins to the SMC were slow. In Version 5.2.21, to mitigate this problem, the ybd-telegraf service is disabled by default.

Instead of being garbage-collected, table deletes were included in full backups, making the backup bundle grow very large.

Unsupported ybunload operations timed out instead of failing immediately.

When a regular user ran a cross-database query that referenced a LANGUAGE SQL UDF in a remote database, the query failed with an error:

ERROR: function with OID nnnnnnn does not exist

Incorrect implicit casting with string functions resulted in a full table scan.

For security reasons, the google-gson dependency for backup and restore was upgraded to 2.9.1.

On the Andromeda platform, spill queries assigned to the large resource pool ran out of memory.

A query with multiple rewritten IN lists that constrained the same constants and referenced these constants in the GROUP BY clause returned the following error:

Variable not found in subplan target list

CREATE EXTERNAL TABLE failed with the following error after a large number of table creations:

OutOfMemoryError: Direct buffer memory

A common table expression (CTE) with an ORDER BY clause returned wrong results.

ACLs defined with ALTER DEFAULT PRIVILEGES on the replication source system were not replicated to the target appliance. To change this behavior, add the following option to the WITH clause of the ALTER DATABASE ADD REPLICA statement:

user_resolution_mode 'PLACEHOLDER'

A rare race condition between spilling and join cleaning code resulted in a worker crash. This crash was more likely to occur for join queries that spill to disk under heavy memory pressure.

A worker crash caused by a race condition could occur while using partitioned tables when join queries involved spilling.

The ybbackupctl --fix-bundle-paths command always returned an exit code of 0. In Version 5.4.2, if any backup paths cannot be fixed, this command correctly returns an error.

The documentation was updated to clarify the description of the last_value column in the sys.sequence view.

When an IN list subquery containing LIMIT and ORDER BY clauses was decorrelated, the IN list rewrite was incorrectly applied, causing wrong results. In Version 5.4.1, decorrelation of IN list subqueries containing LIMIT clauses results in the following error:

This form of correlated subquery is not supported.

ORDER BY clauses were removed from IN list subqueries that included a LIMIT clause, causing queries to return wrong results.

When temporary tables were being created, a rare race condition involving the allocation and vacuuming of associated ROWUNIQUE values could cause a system crash.

During an upgrade to 5.2.18 or earlier, some query_id and session_id numbers were reduced, resulting in duplicated entries in the sys.log_query and sys.log_session views.

Version 5.4.0 addresses some vulnerabilities to the SMC, Lime, and Postgres ports by disabling all weak CBC ciphers.

Views created in Version 5.2.15 and earlier that include CASE expressions would sometimes return errors.

During an upgrade, some tables appeared to be vacuumed when they were not, sometimes causing SQL statements to return the following error:

ERROR: could not access status of transaction
DETAIL: Could not open file "pg_clog/0000"

Version 5.4.0 addresses some vulnerabilities in the Yellowbrick ssh configuration.

An IN list rewrite would sometimes return wrong results because data was not cast to the correct data type.

During an upgrade, a table containing duplicate keys that returned a duplicate key value error would cause the upgrade to fail.

A memory allocation issue would cause a crash in the manager node stack.

In some instances, a hung monitoring service was not terminated, causing a manager node failover to be unsuccessful and resulting in both manager nodes becoming secondary.

Insufficient system pool memory would cause some GC operations to stall.

A hung query was not present in the sys.query view and would not respond to yb_terminate_session, preventing a GC operation.

When a blade was being booted, the ybcli blade status command incorrectly reported "Cluster Status: ERROR."

Using ybcli maintenance mode for DNS changes could cause issues with the port listener.

After an upgrade to 5.2.13 or 5.2.14, replication source databases unable to reach the target system were put in READONLY mode with no additional attempts to connect to the target. In Version 5.4.0, the system retries connections to the target system for 10 minutes, bringing the source database out of READONLY mode if the target is available.

Using DISTINCT inside the MEDIAN function would cause the system to crash.

Parsing a query with a complex nested case expression would sometimes cause out-of-memory errors and a system crash.

After an upgrade, some front-end queries would return the following warning:

WARNING: out of shared memory.

The installation preupgrader could terminate early when validating tables with only system attributes.

Version 5.4.0 improves the ability to set multiple domains on the network manager.

Toast tables and indexes related to schema-excluded objects were not excluded during the replication cycle, resulting in orphaned relations and ultimately causing a database restart.

When executed in an aborted transaction, a ROLLBACK TO SAVEPOINT query would not be removed from the sys.query view.

A CTAS statement that included a common table expression caused a Postgres crash.

Character strings inside a NULLIF expression returned wrong results because auto-trimming was not applied to them.

Queries including conversions of CHAR to DATE data type would sometimes return an out-of-range error.

Issues during query execution caused simple correlated subquery usage in the predicate to result in a database crash.

The description of ALTER DATABASE DROP REPLICA was improved in the 5.4 documentation.

Misleading histogram statistics were being created for certain table distributions, leading to inefficient query plans and slower performance.

In Version 5.4.0, performance of query compilation and code generation was improved.

When a replicated view contained a UDF that was used by a subquery, selecting from the view on the destination database returned a "cache lookup failed" error.

After an upgrade to 5.2, replication failed on the source system with backup errors because of a problem with duplicate "relfilenodes."

A query with a very large IN list returned a "KE002: Out of Memory" error.

A query with an IN list condition containing a GROUP BY, DISTINCT, or ORDER BY operation applied after the cast would return the following error:

ERROR: variable not found in subplan target list

Using ALTER statements to rename database objects would allow new names to include line breaks, which resulted in errors when such objects were used in a CREATE TABLE AS statement. In Version 5.4.0, newlines are not permitted in object names.

The pre-upgrade script returned a Python error when the --only flag was used. In Version 5.4.0, you can use this option to run a single check on all databases. You can use the --database option to run all pre-upgrade checks on a single database. You can run a single check on a single database by using both options together. (These command-line options are not supported in ybcli.)

Failure of a GC operation resulted in a "Metadata storage full error."

Performance of scans against the sys.fsinfo virtual table was improved.

On 3-chassis and 4-chassis systems, the server crashed while running queries against the sys.fsinfo virtual table.

When implicit casting was used for subqueries that included ORDER BY, GROUP BY, or DISTINCT clauses, the clauses were applied to the incorrect data type, sometimes resulting in a Postgres crash.

INSERT statements that required implicit casts on numeric constants inserted garbage values into the table.

An internal setting for worker spill space could not be retrieved and caused a Postgres crash.

Improvements were made to the check_xfs.py script to prevent hanging.

When a backup contained only a large number of table deletes, a ybrestore operation exceeded a configurable timeout in the restore service, causing the restore to error out although it was complete.

The presence of unicode characters in short character strings could cause incorrect compression and wrong results when the strings were compared.

Certain join queries returned a Generic UnexpectedException error when they contained a LIMIT clause but no ORDER BY clause.

Memory for all joins was over-estimated as a result of a previous fix for skew handling.

ybload failed to round up input data with a fractional second value of more than six digits of precision, resulting in the row being skipped.

When a bulk load failed, a race condition could cause the SMC to report incorrect status and health for the cluster.

Under certain conditions, running the ybdumpschema tool took significantly longer than expected.

On the Andromeda platform, spilling scalability was improved for aggregations.

To ensure that the Yellowbrick server and client tools are not subject to known log4j vulnerabilities, unused packages and their dependencies were removed from the log4j distribution used by Yellowbrick.

On the Andromeda platform, a prioritization issue involving heartbeat signals would sometimes cause a heartbeat failure on large clusters.

For loop joins, the planner sometimes did not choose the smaller table to hold in memory.

Postgres crashed because of a problem with processing ACL settings when roles were set with the ALTER ROLE command.

SEMI RIGHT joins could return wrong results because of a race condition. Any query of the following form could trigger this behavior, especially larger, partitioned queries:

SELECT a from foo where a IN (select b from bar);

When a stored procedure that created a table with a CLUSTER ON clause was executed, Postgres crashed.

A rare, intermittent worker crash caused by a race condition could occur on the Andromeda platform when queries involved spilling.

When the geqo and geqo_threshold configuration parameters were set explicitly for a cursor-related query, the system crashed.

A planner optimization prevented the deduplication of init plans, causing excessive memory consumption during query compilation.

The ASCII function is now included in the Version 5.4 documentation.

A transaction-consistency check in the FSCK code resulted in an assertion error.

When a join key was also the target of a constant filter, the selectivity of the join was incorrectly estimated.

Backups taken over AWS Private Link failed with a timeout error.

In some cases, ybload could fail with an index out of bounds exception while generating a bad row file.

The description of the w.resourcePool property for WLM rules was improved in the Version 5.4 documentation.

The description of the ybbackup --exclude option was improved in the Version 5.4.0 documentation.

A configuration parameter caused certain queries to return an "unrecognized node type" error.

In Version 5.4.0, a section was added to the backup and restore documentation to explain how to give users access to encrypted table columns in a restored database.

For CASE WHEN expressions with CHAR and VARCHAR types, the implicit casting hierarchy was not followed properly. In Version 5.4.0, a VARCHAR type is returned if there is at least one VARCHAR type in the branches of the CASE expression.

A new configuration parameter was implemented to allow string functions such as TRIM to be ignored when selectivity of a clause that contains these functions is estimated.

A misconfiguration of the code generation service during system startup would sometimes cause the service to be unavailable.

A Postgres crash occurred because of problems with processing nested NOT IN subqueries.

At some point in the cycle, a database restore would hang. All activities dropped to 0, as indicated by the read/write network statistics in the log.

The used_bytes column in the sys.storage view is described incorrectly in the documentation of earlier versions. The used_bytes value is not a precise sum of other values in the view. You cannot derive the exact amount of space used per worker; used_bytes is an approximation, roughly equal to:

distributed_bytes + replicated_bytes + random_bytes + scratch_bytes + some overhead

The SMC showed a value of 0 for temporary space when the limit was set to 20%.

When a column name was used in the flags argument, the REGEXP_LIKE function returned the error "RPC channel broken" causing workers to crash. Version 5.4.0 returns the following expected error for this case:

ERROR: Flags found in REGEXP must be a string literal

Under certain conditions, an INSERT query that was restarted in a different WLM resource pool could cause data loss. For more details, request the Support Bulletin on this topic from Customer Support.

A CREATE VIEW statement with a CASE expression now returns VARCHAR columns with the correct width.

A security issue made it possible for users to drop database objects that they did not own.

The ybloadcat and ybdumpcat logs were missing during an upgrade. In Version 5.4.0, verbose mode is the default for upgrades so that pg.log files are redirected to the ybinstaller.log.

The SMC displayed the creator of the WLM profile as the user who activated the profile, rather than the actual user who activated it.

The output of ybdumpcat now includes the number of rows exported from each table.

Improvements were made to the preupgrade script to log deletes for system catalog tables.

Log messages were added to the pg.log when table delete records were inserted for pg_class or pg_type. When a DROP TABLE is executed, check the pg.log for a line of the form:

inserted td record oid <oid of dropped table> in relid 1259...

Detection of composite primary-key/foreign-key relationships did not take the error margin for distinct values into account, resulting in the wrong join order being chosen.

The number of distinct values was poorly estimated for expressions of the form:

func(var) = <const>

These estimates have been improved in Version 5.4.0.

Using the ybd_analyze_after_writes configuration parameter returned an unexpected warning, which could interrupt automation scripts.

For primary-key/foreign-key join estimation on composite keys, the cardinality was estimated as the size of the primary key, not the foreign key.

The TO_NUMBER function returned a compile error when a NOT NULL constraint was defined on the column used for the first argument.

A rare race condition could cause a restore or replication failure.

The Infiniband route-determination algorithm was changed from Min Hop to LASH to prevent issues in large multi-chassis systems.

Database restore operations could hang when network environment settings caused the termination of connections that were idle for a long time. In Version 5.4.0, the length of time that a network connection can remain idle for large data transfers has been reduced.

The sys.cluster view logged duplicate rows for the same worker with multiple roles. Because of this problem, the cluster failed to start.

Join queries run under low-memory conditions (in a slot only a little larger than the estimated memory requirement) triggered repeated spill cycles and failed with an assertion error.

The compiler was overly aggressive in its memory consumption for large queries.

A query against the sys.query view with an IN list condition returned wrong results.

The NVL/COALESCE function returned wrong results because trailing space characters were not trimmed correctly.

Entries from yb_deletes tables were included in sys.aalog (AutoAnalyzeLog), resulting in a reduction of disk space and slower auto-analyze performance.

Database users granted "Manager" privileges in the SMC were unable to view queries executed by other users.

Under memory pressure, a rare issue occurred with compute blades writing compiled queries to disk.

In some instances, queries that should have been restartable were unable to restart.

Several system views with privilege checks incorrectly omitted tables in other databases for non-superusers.

DECIMAL values lost precision when implicit casting was used for subquery results in set operations, such as UNION and UNION ALL.

An upgrader issue would prevent autovacuum from running on some tables, sometimes causing Postgres to emit the following warning:

WARNING: some databases have not been vacuumed in over 2 billion transactions

Spilling a join that is skewed would sometimes result in an out-of-memory (OOM) condition if the skew value exceeded the memory.

Version 5.4.0 increases memory requirements for all queries with table scans.

Changes to join ordering introduced in Version 5.2.0 caused unintended changes to joins used in views. For example, LEFT joins became FULL joins. In Version 5.4.0, the original join ordering is restored for views.

Version 5.4.0 improves cardinality estimations of composite keys.

The Postgres acl_explode() function returned the following error when the ACL abbreviation "Z" was part of the input to the function:

SQL: ERROR: unrecognized aclright:8388608

When parquet files with unsigned INT64 data were loaded via ybrelay and Spark, the load failed with the following error:

Parquet types not supported: INT64 (UINT_64)

To load unsigned INT64 data in Version 5.4.0, you can use the new ybload feature for loading parquet files, or you can upgrade to Spark 3.2.

Under certain conditions, running the ybcli system status command on the Andromeda platform would incorrectly report the platform as Tinman.

When queries failed with out-of-memory errors, a race condition resulted in a worker crash.

The system could be left in a hung state when queries with very complex regular expressions were submitted. In Version 5.4.0, when a regex expression is too complex, the query returns an error that specifies the regex pattern that caused the problem:

Regex '<pattern>' is too complex. Exceeded maximum number of state transitions

In addition, "yielding" inside the regex engine has been introduced, such that before a regex pattern is declared as "too complex," system stability is improved for complex patterns that do not reach the maximum number of state transitions.

Under certain conditions, compiling queries with large IN lists would return an out-of-memory error.

A CTAS query that returned an error during parsing or planning logged a type of "create table as" in sys.log_query instead of the expected "ctas" type.

Casting a two-digit year CHAR string stored in a table to a DATE data type failed with the following error:

ERROR: datetime field overflow

After a manager node failover, a rare race condition could cause the logging service of the secondary node to stop working, resulting in a loss of logs on that node.

When the result of an IN list subquery required a cast, the query failed with the following error:

Missing constant for test expression

In Version 5.4.0, the cast that is applied to the result of an IN list subquery is pushed down into the subquery.

Queries with CASE WHEN expressions would sometimes become stuck in lime in a prepare state.

Running the DESCRIBE command on tables with VARCHAR set as the default displayed an unnecessary cast.

A query with a large number of OR clauses failed after fifteen minutes with the following error:

ERROR: Query too complex.

Version 5.4.0 improves the compile time for queries containing nested subqueries.