Skip to content

Yellowbrick Data Warehouse Version 4.1 Change History


4.1.16 Yellowbrick Release Notes

Release Date: 12/23/2024

Upgrade Requirements

The following information highlights some critical aspects of the migration from Version 3.x or 4.0.x to 4.1.x. For full details and guidance through the complete upgrade process, consult Customer Support.

  • Version 3.3.x or higher is a prerequisite for upgrading to 4.1.x.
  • You can upgrade directly to 4.1.x from Version 3.3.x or any later 3.x version. You do not have to upgrade to 4.0.x first.
  • Specific one-time procedures are required as part of an initial Version 4.x upgrade from version 3.x; contact Customer Support to review the process and schedule the upgrade.
  • For upgrades from Version 3.x, running the pre-upgrade script is critical and should be scheduled weeks in advance of the upgrade itself. A network upgrade and a manual shard rewrite process are also required once the software upgrade is complete. These steps are not required for upgrades from Version 4.0.x.

Java Upgrade

On all Version 4.1 appliances, the JVM version has been updated to OpenJDK 1.8.0_252 or higher. Yellowbrick is using the OpenJDK bundle distributed by Red Hat, which includes default support for a new version of the garbage collector (GC). The Yellowbrick installer will install the necessary packages and configure the environment. No manual steps are required to complete this upgrade.

ybtools Compatibility

It is recommended that ybtools always be upgraded to match the version of the Yellowbrick Data Warehouse against which it is being used (for example, Version 4.1). Using Version 4.1 of ybtools with an older server version (such as Version 3.3 or 4.0) may result in error messages for some commands. Using previous versions of ybtools with a Version 4.1 data warehouse is likely to work but is deprecated and not supported. See also the following section: Backward Compatibility for Backup and Restore.

Important

On CentOS and Red Hat client platforms, you must first remove any existing 3.x version of ybtools. Then you can proceed with the installation of the Version 4.1 ybtools. You cannot upgrade directly from an earlier 3.x version of ybtools to Version 4.1.

Replication Compatibility

Both systems used for database replication (source and target) must be running the same version of the database software (for example, 4.1.7 and 4.1.7). For example, you cannot replicate from a 4.0.x source to a 4.1.x target.

Backward Compatibility for Backup and Restore

A backup taken in Version 3.2.x, 3.3.x, or 4.0.x prior to a 4.1 upgrade can be restored in Version 4.1.

After a 4.1 upgrade or installation, the previous version of the backup and restore tools is compatible with Version 4.1. The Version 4.1 ybtools package installs two sets of backup and restore tools: legacy tools and new 4.1 tools.

*The legacy tools are deprecated and will be removed in a future release, along with the ability to restore backups taken in Version 3.x releases. *There are significant differences in the functionality and client tool options between the legacy tools and the new tools. The tool sets are distinguished by their names:

ybtools VersionBackupRestoreList/Manage Backups
New in Version 4.xybbackupybrestoreybbackupctl
Legacy in Version 4.xybbackup-oldybrestore-oldybbackup-list-old
Version 3.xybbackupybrestoreybbackup-list

To use the legacy tools in the 4.1 package, be sure to use the correct tool name in the command. For example, to return help for the legacy version of ybbackup:

$ ybbackup-old --help
Yellowbrick Backup and Restore version 4.1.1-24981
...

Important

To use backup and restore in Version 4.1, you must follow these steps:

  1. Use the legacy version of ybtools to restore your 3.x backups into 4.1 databases.
  2. Take new full backups of your 4.1 databases with the new 4.1 ybtools.
  3. Stop using the legacy ybtools for backup and restore purposes. Use only the new tools.

What's New in Version 4.1.16

Version 4.1.16 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.15

Version 4.1.15 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.14

Version 4.1.14 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

extra_float_digits

In Version 4.1.14, the extra_float_digits parameter is included in the results of the SHOW ALL command. This parameter controls the number of extra significant digits that are included when a floating-point value is converted to text for output. The default value is 0. Increasing the number to 1 or greater produces output that more accurately represents the stored value.

What's New in Version 4.1.13

Version 4.1.13 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.12

Version 4.1.12 provides one critical bug fix for an issue reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.11

Version 4.1.11 provides one critical bug fix for an issue reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.10

Version 4.1.10 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.9

Version 4.1.9 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.8

Version 4.1.8 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.7

Version 4.1.7 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

Operational Changes in Version 4.1.7

The ybtools package is no longer supported on RHEL and CentOS 6 platforms, which were declared EOL on November 30, 2020.

What's New in Version 4.1.6

Version 4.1.6 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

Operational Changes in Version 4.1.6

The output formula for the ENCRYPT_KS and DECRYPT_KS functions changed between Versions 3.x and 4.x. In Version 4.1.6, the Version 3.x behavior is used when algorithms 1, 2, and 3 are explicitly specified as constants. See the Version 4.1 documentation for more details.

What's New in Version 4.1.5

Version 4.1.5 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.4

Version 4.1.4 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.3

Version 4.1.3 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

Operational Changes in Version 4.1.3

In Version 4.1.3, TRUNCATE operations revert to their pre-4.0 behavior. Therefore, a TRUNCATE is no longer the same as an unqualified DELETE operation; TRUNCATE operations are faster. However, table delete records are written for both TRUNCATE and DELETE operations.

What's New in Version 4.1.2

Version 4.1.2 provides critical bug fixes for issues reported by customers. See Issues Fixed in Version 4.1.x.

What's New in Version 4.1.1

Version 4.1.1 provides critical bug fixes for issues reported by customers.See Issues Fixed in Version 4.1.x. All customers who have Version 4.1.0 already installed are encouraged to upgrade to this release.

Operational Changes in Version 4.1.1

The following list describes significant changes in behavior between Version 4.1.0 and Version 4.1.1.

  • You can now create WLM rules that filter on the "ycopy" command type. See "Managing the Row Store" in the Version 4.1 documentation.
  • The ybcli system status command now returns two row store lines, one for the main Yellowbrick row store and one for the system catalog row store.

What's New in Version 4.1.0

Version 4.1.0 contains the following new features and enhancements. Also note that there are some significant changes in behavior.

New Features

The following new features are introduced in Version 4.1.

Yellowbrick Row Store

The Yellowbrick row store has been enhanced to improve performance for trickle-feed workloads, to provide options for managing the behavior when the row store becomes full, and to store and reclaim table data more efficiently in both the row store and the column store.

Bulk Loads from Object Storage

The ybload client tool supports bulk loads from the following types of object storage:

  • Azure Blob containers
  • AWS S3 buckets (enhanced functionality in this release)
  • Object stores for other S3-compatible providers

New and Updated ybload Options

  • --num-cores is a new option that you can use to control the number of cores on the host system that will be used for ybload operations.
  • **--read-sources-concurrently **has been enhanced in this release. See the discussion of advanced ybload options in the Version 4.1 documentation.

Encryption of Data at Rest

Encrypted columns can be declared in CREATE TABLE statements, then automatically loaded, stored, and queried in a protected format. Only authorized users may decrypt the data in these columns. Several encryption options are provided, including deterministic and randomized OFB algorithms.

Fine-Grained Access Privileges

A range of GRANT and REVOKE commands at different levels provide mechanisms for creating a fine-grained security model. You can grant access privileges (ACLs) on various database objects (or on the system) to one or more users or roles. Objects can be individually secured or secured in the context of a schema, database, or the system itself.

You can grant or revoke several new privileges at the SYSTEM or DATABASE level:

  • CREATE USER or ROLE ON SYSTEM
  • ALTER ANY USER or ROLE ON SYSTEM
  • DROP ANY USER or ROLE ON SYSTEM
  • RESTORE ANY DATABASE ON SYSTEM
  • CREATE DATABASE ON SYSTEM
  • EXPLAIN QUERY ON DATABASE
  • VIEW QUERY TEXT ON DATABASE
  • TRACE QUERY ON DATABASE
  • BACKUP ON DATABASE
  • RESTORE ON DATABASE

New and Enhanced SQL Functions

The following SQL functions have been added:

  • HMAC and HMAC_KS: These functions generate an HMAC for an input string and a secret. The HMAC_KS function accepts an encryption key for the secret.
  • ENCODE: This function converts an input string from hexadecimal to base64 encoding.
  • NYSIIS: This function returns the phonetic representation of a string by applying the New York State Identification and Intelligence System (NYSIIS) algorithm.
  • sys.ldap_sync(): This function synchronizes users and groups in your LDAP configuration.
  • The HAS_DATABASE_PRIVILEGE function has been enhanced to support new privileges.

Operational Changes in 4.1.0

The following list describes significant changes in behavior between Version 4.0 and Version 4.1.

  • The maximum number of databases per appliance has been increased to 1,000. This limit includes the yellowbrick database, so the effective maximum number of user-created databases is 999. In previous releases, the limit was 128 databases.
  • You can now use the DESCRIBE command to describe stored procedures.
  • The DESCRIBE output for table DDL now includes constraints.
  • The COMMENT ON command now supports comments on constraints in tables.
  • The CREATE KEY command now accepts the IF NOT EXISTS option.
  • When the current database is READONLY, CREATE DATABASE and DROP DATABASE commands are allowed.
  • VARCHAR(ANY) and VARCHAR(MAX) are now aliases for VARCHAR(64000).
  • Timezone support has been enhanced to include the following IANA time zone names:
    • America/Punta_Arenas
    • Asia/Atyrau
    • Asia/Famagusta
    • Asia/Tomsk
    • Asia/Yangon
    • Canada/East-Saskatchewan
    • Europe/Kirov
    • Europe/Saratov
  • Double quotes are no longer supported within database names and other object names.
  • The rowstore_write_limit_gb configuration parameter has been disabled. See the Version 4.1 documentation for information about new controls for managing the row store in this release.
  • The ybload --read-sources-concurrently option can now be set to a number of sources, in addition to the existing settings.
  • "Path-style" URIs are no longer accepted for loads from AWS S3. See the ybload documentation (object storage options).
  • A system-defined alert has been added for LDAP synchronization failures.

SQL Command Updates

The following SQL commands are updated in Version 4.1:

  • ALTER TABLE
  • COMMENT ON
  • CREATE KEY
  • CREATE TABLE
  • DESCRIBE
  • GRANT and REVOKE

System View Updates

The following system views are new or changed in Version 4.0:

  • sys.column (new encrypted column added)
  • sys.role (new superuser column added)
  • sys.table (new rowstore columns added)
  • sys.database (new information in the acess_privileges column)

Recommendations for Use of SMC roles

Yellowbrick Data recommends that database superusers logging into the SMC are configured as a member of the Administrator role (sys_ybd_smc_admin).

Known Issues

You may encounter the following issues in Version 4.1.x:

Issue #Description
20786Running EXPLAIN ANALYZE on any write statement (INSERT, UPDATE, DELETE) modifies the underlying table, without warning. To work around this problem, run the EXPLAIN ANALYZE statement inside a transaction so you can roll it back if needed.
15784, 16097When the row store becomes full (which triggers a MAJOR alert), DELETE operations may fail and some statistics about running queries may be lost.
16101The SMC does not display row counts in the row store (for example, in the Table Details screen).
15523In rare cases, the row store may become full because of excessive logging into a system table used for query execution history. If this problem occurs, contact Customer Support.
14447If you use a full restore to seed a replica, you must start replication by specifying the chain name in the ALTER DATABASE command. For example:

yellowbrick=# alter database sourcedb alter replica sourcedb_replica
start with chain 'February2020';
START REPLICA

If you do not specify the chain, the first replication cycle will duplicate the seeded table rows. For details about seeding a replica, see the "Database Replication" section in the Version 4.1 documentation.

Issues Fixed in Version 4.1.x

The following issues were fixed in Version 4.1.x releases.

ReleaseIssue #Description
4.1.1621249To 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. Specifically:

1. The RHEL log4j package and RPMs have been removed from the manager node.
2. The log4j jar used by Yellowbrick on the manager node has been replaced with yb-log-4.1.16.jar, which does not contain the vulnerable classes (JMSAppender, JMSSink, SimpleSocketServer, and SocketServer).
3. The log4j jar used by ybtools has been replaced with yb-log-4.1.16.jar, which does not contain the vulnerable classes (JMSAppender, JMSSink, SimpleSocketServer, and SocketServer).
4.1.1620821A section was added to the Version 4.1 backup and restore documentation to explain how to give users access to encrypted table columns in a restored database.
4.1.1620760A Postgres crash occurred because of problems with processing nested NOT IN subqueries.
4.1.1620722In some situations, the ybrestore tool did not abort a restore operation in a timely manner when errors occurred during the data load part of the operation.
4.1.1620712The used_bytes column in the sys.storage view is described incorrectly in the Version 4.1 documentation. 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
4.1.1620127A workaround was implemented for a problem with missing table deletes during replication. Contact Customer Support for details.
4.1.1619980Replication became stuck and returned the following error when the names of tables were swapped (via ALTER TABLE) and another table was dropped:

Error running YCATALOGRESTORE: could not open relation with OID 3405720, DBOID 0
4.1.1619375A restore failure was caused by missing missing deletes in the backup bundle.
4.1.1617652, 17559Additional PostgreSQL call stacks were marked as SAFE so that crashes during execution affect the current session only, instead of closing all sessions.
4.1.1520653A security issue made it possible for users to drop database objects that they did not own.
4.1.1520621Log 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...
4.1.1520492Database restore operations could hang when network environment settings caused the termination of connections that were idle for a long time. In Version 4.1.14, the length of time that a network connection can remain idle for large data transfers has been reduced.

This fix does not require a server change; the ybtools client can be installed separately and will work with server versions 4.1.9 and later. (If the server version is 4.1.8 or earlier, this fix will have no effect.)
4.1.1518556When restoring large backup bundles, restore operations sometimes failed and reported an "invalid key" error.
4.1.1420052The SHOW ALL command did not list the value of the extra_float_digits parameter.
4.1.1420044Queries could crash because incorrectly sized strings were generated when the extra_float_digits parameter was set to 3.
4.1.1419944A row store DELETE failed when a sub-transaction was aborted.
4.1.1419397Failed delivery of updateStatus() messages could cause ybload to hang.
4.1.1418560Users were unable to query views in a given database if the view contained references to UDFs defined in another database. Version 4.1.14 enables cross-database support for views with UDFs.
4.1.1319538, 17878During database replication, a restore operation ran out of memory because of an edge case where the data input node exhausted its buffer pools.
4.1.1319529DELETE statements could cause duplicate rows to be inserted into the yb_deletes_* table.
4.1.1318671False PSU alerts were being issued from the CMPs.
4.1.1318559Queries with certain LIKE expressions could result in a system crash. In Version 4.1.13, LIKE expressions with no wildcards, or only leading and trailing wildcards, are rewritten to reduce the regex compilation overhead.
4.1.1318590The database would not start because of a large query cache.
4.1.1219228Under certain circumstances, repeated failovers using a replica that had been dropped and re-created would result in missing metadata on the target system and replication could not continue.
4.1.1119265A query with a large number of COUNT(DISTINCT) functions caused Postgres to run out of memory. In Version 4.1.11, you can set a configuration parameter, max_count_distincts, which defines the maximum number (from 1 to 1000) of COUNT(DISTINCT) functions in a query. The default is 0 (unlimited).
4.1.1019201A restore operation failed when table deletes were missing from the backup bundle. In Version 4.1.10, additional logging has been added to the vacuum process to track table deletes more accurately.
4.1.1019173The preupgrade script required more checks to be run for foreign-key dependencies.
4.1.1019171Database replication required more detailed logging for debugging purposes. In Version 4.1.10, when ybd_enable_replication_logging is set to "true," the catalog backup and restore bundle is logged to pg.log.
4.1.1019168, 19167, 19157Several types of orphaned dependencies were not ignored in system catalog backups, causing backup and replication failures.
4.1.1019095Queries against a view returned incorrect results when the base table was re-created with a column in a different ordinal position. For example: 
create table t (a int, b int, c int);
create view v as select count(*) from t where c = 3;
drop table t;
create table t (c int, b int, a int);

The view now applies the WHERE clause incorrectly as:

where a = 3

Prior to upgrading to Version 5.1.1, you can work around this problem by dropping and re-creating the view.
4.1.1018952The rowstore did not properly clean up the state of a failed query when only a savepoint inside a transaction was aborted and not the transaction itself.
4.1.1018655An UPDATE with a join that returned multiple matching rows from data in the rowstore succeeded when it should have returned the following error: 

Attempt to update a target row multiple times.
4.1.1016663A Postgres crash occurred when a correlated subquery was used in the HAVING clause, combined with a COUNT(DISTINCT) function in the select list of the outer query. In Version 4.1.10 (and Version 5.x), decorrelated expressions are supported in the HAVING clause.
4.1.918444Replication failed after an upgrade from Version 4.1.x to Version 4.1.7 or 4.1.8.
4.1.918441Replication returned the following error:

YCATALOGRESTORE: duplicate key value violates unique constraint pg_default_acl_role_nsp_obj_index

To solve this problem, in Version 4.1.9, pg_default_acl is not restored if ACLs are not being restored or missing users are being mapped to the database owner (--security-mode NONE).
4.1.918200Replication cycles could hang when network environment settings caused the termination of connections that were idle for a long time. To solve this problem, the length of time that a network connection can remain idle for large data transfers has been reduced.
4.1.917986An INSERT using the RETURNING statement did not return the correct result set.
4.1.917953The logging level of the Protegrity server has been increased (when logging is enabled). Remote logging is also available in this release.
4.1.818280When INSERT and TRUNCATE operations were run on the same table in the same main transaction but different sub-transactions, and a concurrent backup was running while the transaction was open, shard store records became out of synch with backend storage. Therefore, a subsequent FSCK would fail.
4.1.718044An ENCRYPTED table column was not decrypted when it was referenced in a cross-database query.
4.1.718036A system ran out of disk space because log rotation was not working correctly and the pg.log file became too large.
4.1.718011ybunload would hang when the target system ran out of space for writes.
4.1.717984Output file "chopping" was improved for ybunload operations that use block mode compression.
4.1.717976During replication, a backup operation timed out when it took too long to process table deletes that spilled.
4.1.717845When the relayBufferedWriter.write Java API was used with ybrelay, some records failed to load into the database.
4.1.717833An upgrade from 4.1.4 to 4.1.6 failed with the following error:

authentication method "ldap" requires argument "ENV:YBDMASTERKEY" to be set
4.1.717780A \copy command failed when it tried to load >30MB into a table with a mixed-case name.
4.1.717741A DELETE query that required decorrelation returned the following error:

This form of correlated subquery is not supported.
4.1.715520During replication and restore operations, the application of a large delete on the target system could spill and run out of space. Any WLM rules that were created on the target to re-route DELETE queries for replication and restore operations to larger slots should be removed.

In Version 4.1.7, the default WLM rule set should be sufficient to handle the application of arbitrarily large DELETEs and TRUNCATES on the target system. Large DELETEs are broken into several smaller DELETEs that will not spill and will scale according to the slot size of the WLM resource pool.
4.1.713187Using the Query view or Query Performance view in the SMC could cause Postgres to crash.
4.1.617776A query grouped by the primary key of a table allowed other, non-aggregated select list columns to be omitted from the GROUP BY clause, resulting in a software crash. In Version 4.1.6, a query of this kind returns the expected error: 
ERROR: column <name> must appear in the GROUP BY clause or be used in an aggregate function
4.1.617742, 17694A replica seeded with a restore operation incorrectly set the rollback snapshot on the first replication cycle.
4.1.617695Queries that generated large ASTs returned a compiler error and required a database restart. In Version 4.1.6, a memory leak was fixed, and a database restart is no longer required. The manager node runs a "watchdog" service that cancels queries if they take longer than 30 minutes to compile. If you occasionally see queries that take longer to compile, contact Customer Support. If necessary, it is possible to disable the watchdog or change the timeout.
4.1.617680An UPDATE with duplicate source rows resulted in an extra inserted row.
4.1.617679, 17711The output formula for the ENCRYPT_KS and DECRYPT_KS functions changed between Versions 3.x and 4.x. In Version 4.1.6, the Version 3.x behavior is used when algorithms 1, 2, and 3 are explicitly specified as constants. See the Version 4.1 documentation for more details.
4.1.617630Queries with joins containing COUNT(DISTINCT) and certain expressions of the form "f(columnA) = X or f(columnA) = Y" could cause a crash.
4.1.617606In a PL/pgSQL anonymous block or stored procedure, a COMMIT following an INSERT generated a YRS error.
4.1.617594A prepared statement with an expression in the ORDER BY clause returned a "cannot ORDER BY on a parameter" error.
4.1.617591Although concurrent YCOPY operations are allowed on the same table, for partitioned tables, each YCOPY tried to update the same entry in the partstats system table at the same time.
4.1.617580A fatal exception in BulkLoadState leaked a JDBC connection with a transaction open, preventing garbage collection and causing systems to fill.
4.1.617569When a transaction was aborted and its sub-transaction dropped a table, the lock on the table was released too early, causing a worker crash.
4.1.617532After an upgrade from Version 4.1 to a later 4.1.x version, the has_system_privilege function returned an "ACL arrays must be one-dimensional" error.
4.1.617516In some cases, queries with joins containing COUNT(DISTINCT) and HAVING clauses that referenced grouping columns could cause a crash.
4.1.616883, 17613INSERT INTO VALUES statements that contained function references were executed on the worker nodes. In Version 4.1.6, this behavior only occurs when an INSERT contains encryption functions.
4.1.617453The "watchdog" service on the manager node incorrectly initiated a failover when an I/O error occurred.
4.1.614764Correlated subqueries with LIMIT and OFFSET clauses returned inconsistent results. In Version 4.1.6, correlated scalar subqueries are restricted to LIMIT values of 0 or 1 and/or an OFFSET value of 0. Other LIMIT and OFFSET values will cause these queries to return an error.
4.1.517555FSCK failed after a cluster was reconfigured.
4.1.517552LIKE (and ILIKE) expressions in prepared statements failed with an error after an upgrade to Version 4.1.4.
4.1.517507The collect_stats and load_stats utilities failed when table names contained spaces and quotes.
4.1.517491A worker crashed after a query returned a "WLM row limit of 5000000 exceeded" error.
4.1.517476ybdumpschema failed for a hash-distributed table with a distattnum of 0.
4.1.517443The preupgrade script did not properly check for invalid OIDs, causing upgrades from Version 3.x to 4.x to fail.
4.1.517293The upgrade catalog importer failed because temporary tables had not been cleared.
4.1.517255, 16451An intermittent crash occurred in the restore node.
4.1.517250A cross-database CTAS created a table with DISTRIBUTE RANDOM although the source table was DISTRIBUTE REPLICATE.
4.1.516989In rare cases when a query crashed, records remained in runtime stats tables, giving the appearance that the query was still running.
4.1.417202The legacy version of the ybbackup tool wrote a large number of duplicate entries to the sys.backup_shards table, causing apparent hangs in Postgres when records were deleted.
4.1.417184Postgres crashed during cleanup of dead records in sys.rowunique.
4.1.316951The description of the "Drop dangling users/roles" option for LDAP synchronization was not clear. The Version 4.1 documentation has been updated.
4.1.316913A query with a nested-loop-join node returned an incorrect assertion error.
4.1.316906DELETE queries failed with "permission denied" errors on internal yb_delete_* tables.
4.1.316722The DROP BACKUP CHAIN command was not documented. The Version 4.1 documentation has been updated.
4.1.316702UPDATE join operations on tables with REPLICATED distribution produced wrong results when the target table was on the build side of the join.
4.1.316974A worker crashed with a segmentation fault while checking I/O timeout on the NVMe drives.
4.1.316926In rare cases, some legacy backup bundles (created prior to Version 4.0) could not be restored if they were taken from a source system with lots of row store inserts.
4.1.316585Some UPDATE statements that were run in a UTF8 database and referenced a Win1252 character returned a "Generic UnexpectedException - assertThrow failure."
4.1.316547TRUNCATE performance was slower in Versions 4.0 and 4.1.x. In Version 4.1.3, TRUNCATE reverts to the old pre-4.0 behavior and is no longer the same as an unqualified DELETE. In addition, when TRUNCATE operations are run, table delete records are inserted and shards are renamed.
4.1.316446The rows_deleted column in the sys.log_query view was populated with the wrong value when rows were deleted from replicated tables.
4.1.315062When the WLM row limit was exceeded, a subsequent race condition caused a worker to crash.
4.1.216732Resources were not cleaned up correctly after the execution of queries with multiple sequences.
4.1.116542Some pages in the documentation mentioned the --input option for ybrestore and ybbackupctl, which is not supported. These references have been removed from the Version 4.1.1 documentation.
4.1.116497Integration of the Protegrity add-on caused a problem with pre-Version 4.0 backup bundles.
4.1.116417An unnecessary ACL check for a schema referenced by a table in a view caused a "permission denied" error.
4.1.116333A specific sequence of SAVEPOINT commands (sub-transactions) combined with a DELETE query caused an FSCK failure. Therefore, deleted rows may have reappeared.
4.1.116260A CTAS statement run inside a stored procedure caused Postgres to crash.
4.1.116095Because of a timeout problem, replication failed with the following error:

Found restore in error state. Aborting. Reason: Abandoned due to client inactivity
4.1.116068Garbage collection (GC) operations required by DELETE, TRUNCATE, and UPDATE operations were blocked by the shard rewrite process (after an upgrade), causing space not to be reclaimed until the rewrite finished. (Note that as of Version 4.0, TRUNCATE operations are the same as DELETEs in that they do not release storage.)
4.1.115465Replication failed with the following error:

YRESTORE: Generic UnexpectedException - assertThrow failure

Prior Releases

For information on releases prior to those listed above, please contact Yellowbrick Support

Parent topic:Yellowbrick Documentation