Appearance
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 Version | Backup | Restore | List/Manage Backups |
---|---|---|---|
New in Version 4.x | ybbackup | ybrestore | ybbackupctl |
Legacy in Version 4.x | ybbackup-old | ybrestore-old | ybbackup-list-old |
Version 3.x | ybbackup | ybrestore | ybbackup-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:
- Use the legacy version of ybtools to restore your 3.x backups into 4.1 databases.
- Take new full backups of your 4.1 databases with the new 4.1 ybtools.
- 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 |
---|---|
20786 | Running 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, 16097 | When the row store becomes full (which triggers a MAJOR alert), DELETE operations may fail and some statistics about running queries may be lost. |
16101 | The SMC does not display row counts in the row store (for example, in the Table Details screen). |
15523 | In 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. |
14447 | If 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.
Release | Issue # | Description |
---|---|---|
4.1.16 | 21249 | 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. 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.16 | 20821 | A 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.16 | 20760 | A Postgres crash occurred because of problems with processing nested NOT IN subqueries. |
4.1.16 | 20722 | In 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.16 | 20712 | The 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.16 | 20127 | A workaround was implemented for a problem with missing table deletes during replication. Contact Customer Support for details. |
4.1.16 | 19980 | Replication 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.16 | 19375 | A restore failure was caused by missing missing deletes in the backup bundle. |
4.1.16 | 17652, 17559 | Additional PostgreSQL call stacks were marked as SAFE so that crashes during execution affect the current session only, instead of closing all sessions. |
4.1.15 | 20653 | A security issue made it possible for users to drop database objects that they did not own. |
4.1.15 | 20621 | 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... |
4.1.15 | 20492 | Database 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.15 | 18556 | When restoring large backup bundles, restore operations sometimes failed and reported an "invalid key" error. |
4.1.14 | 20052 | The SHOW ALL command did not list the value of the extra_float_digits parameter. |
4.1.14 | 20044 | Queries could crash because incorrectly sized strings were generated when the extra_float_digits parameter was set to 3. |
4.1.14 | 19944 | A row store DELETE failed when a sub-transaction was aborted. |
4.1.14 | 19397 | Failed delivery of updateStatus() messages could cause ybload to hang. |
4.1.14 | 18560 | Users 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.13 | 19538, 17878 | During 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.13 | 19529 | DELETE statements could cause duplicate rows to be inserted into the yb_deletes_* table. |
4.1.13 | 18671 | False PSU alerts were being issued from the CMPs. |
4.1.13 | 18559 | Queries 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.13 | 18590 | The database would not start because of a large query cache. |
4.1.12 | 19228 | Under 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.11 | 19265 | A 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.10 | 19201 | A 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.10 | 19173 | The preupgrade script required more checks to be run for foreign-key dependencies. |
4.1.10 | 19171 | Database 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.10 | 19168, 19167, 19157 | Several types of orphaned dependencies were not ignored in system catalog backups, causing backup and replication failures. |
4.1.10 | 19095 | Queries 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.10 | 18952 | The 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.10 | 18655 | An 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.10 | 16663 | A 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.9 | 18444 | Replication failed after an upgrade from Version 4.1.x to Version 4.1.7 or 4.1.8. |
4.1.9 | 18441 | Replication 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.9 | 18200 | Replication 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.9 | 17986 | An INSERT using the RETURNING statement did not return the correct result set. |
4.1.9 | 17953 | The logging level of the Protegrity server has been increased (when logging is enabled). Remote logging is also available in this release. |
4.1.8 | 18280 | When 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.7 | 18044 | An ENCRYPTED table column was not decrypted when it was referenced in a cross-database query. |
4.1.7 | 18036 | A system ran out of disk space because log rotation was not working correctly and the pg.log file became too large. |
4.1.7 | 18011 | ybunload would hang when the target system ran out of space for writes. |
4.1.7 | 17984 | Output file "chopping" was improved for ybunload operations that use block mode compression. |
4.1.7 | 17976 | During replication, a backup operation timed out when it took too long to process table deletes that spilled. |
4.1.7 | 17845 | When the relayBufferedWriter.write Java API was used with ybrelay, some records failed to load into the database. |
4.1.7 | 17833 | An 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.7 | 17780 | A \copy command failed when it tried to load >30MB into a table with a mixed-case name. |
4.1.7 | 17741 | A DELETE query that required decorrelation returned the following error: This form of correlated subquery is not supported. |
4.1.7 | 15520 | During 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.7 | 13187 | Using the Query view or Query Performance view in the SMC could cause Postgres to crash. |
4.1.6 | 17776 | A 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.6 | 17742, 17694 | A replica seeded with a restore operation incorrectly set the rollback snapshot on the first replication cycle. |
4.1.6 | 17695 | Queries 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.6 | 17680 | An UPDATE with duplicate source rows resulted in an extra inserted row. |
4.1.6 | 17679, 17711 | 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. |
4.1.6 | 17630 | Queries with joins containing COUNT(DISTINCT) and certain expressions of the form "f(columnA) = X or f(columnA) = Y" could cause a crash. |
4.1.6 | 17606 | In a PL/pgSQL anonymous block or stored procedure, a COMMIT following an INSERT generated a YRS error. |
4.1.6 | 17594 | A prepared statement with an expression in the ORDER BY clause returned a "cannot ORDER BY on a parameter" error. |
4.1.6 | 17591 | Although 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.6 | 17580 | A fatal exception in BulkLoadState leaked a JDBC connection with a transaction open, preventing garbage collection and causing systems to fill. |
4.1.6 | 17569 | When 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.6 | 17532 | After 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.6 | 17516 | In some cases, queries with joins containing COUNT(DISTINCT) and HAVING clauses that referenced grouping columns could cause a crash. |
4.1.6 | 16883, 17613 | INSERT 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.6 | 17453 | The "watchdog" service on the manager node incorrectly initiated a failover when an I/O error occurred. |
4.1.6 | 14764 | Correlated 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.5 | 17555 | FSCK failed after a cluster was reconfigured. |
4.1.5 | 17552 | LIKE (and ILIKE) expressions in prepared statements failed with an error after an upgrade to Version 4.1.4. |
4.1.5 | 17507 | The collect_stats and load_stats utilities failed when table names contained spaces and quotes. |
4.1.5 | 17491 | A worker crashed after a query returned a "WLM row limit of 5000000 exceeded" error. |
4.1.5 | 17476 | ybdumpschema failed for a hash-distributed table with a distattnum of 0. |
4.1.5 | 17443 | The preupgrade script did not properly check for invalid OIDs, causing upgrades from Version 3.x to 4.x to fail. |
4.1.5 | 17293 | The upgrade catalog importer failed because temporary tables had not been cleared. |
4.1.5 | 17255, 16451 | An intermittent crash occurred in the restore node. |
4.1.5 | 17250 | A cross-database CTAS created a table with DISTRIBUTE RANDOM although the source table was DISTRIBUTE REPLICATE. |
4.1.5 | 16989 | In rare cases when a query crashed, records remained in runtime stats tables, giving the appearance that the query was still running. |
4.1.4 | 17202 | The 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.4 | 17184 | Postgres crashed during cleanup of dead records in sys.rowunique. |
4.1.3 | 16951 | The description of the "Drop dangling users/roles" option for LDAP synchronization was not clear. The Version 4.1 documentation has been updated. |
4.1.3 | 16913 | A query with a nested-loop-join node returned an incorrect assertion error. |
4.1.3 | 16906 | DELETE queries failed with "permission denied" errors on internal yb_delete_* tables. |
4.1.3 | 16722 | The DROP BACKUP CHAIN command was not documented. The Version 4.1 documentation has been updated. |
4.1.3 | 16702 | UPDATE join operations on tables with REPLICATED distribution produced wrong results when the target table was on the build side of the join. |
4.1.3 | 16974 | A worker crashed with a segmentation fault while checking I/O timeout on the NVMe drives. |
4.1.3 | 16926 | In 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.3 | 16585 | Some UPDATE statements that were run in a UTF8 database and referenced a Win1252 character returned a "Generic UnexpectedException - assertThrow failure." |
4.1.3 | 16547 | TRUNCATE 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.3 | 16446 | The rows_deleted column in the sys.log_query view was populated with the wrong value when rows were deleted from replicated tables. |
4.1.3 | 15062 | When the WLM row limit was exceeded, a subsequent race condition caused a worker to crash. |
4.1.2 | 16732 | Resources were not cleaned up correctly after the execution of queries with multiple sequences. |
4.1.1 | 16542 | Some 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.1 | 16497 | Integration of the Protegrity add-on caused a problem with pre-Version 4.0 backup bundles. |
4.1.1 | 16417 | An unnecessary ACL check for a schema referenced by a table in a view caused a "permission denied" error. |
4.1.1 | 16333 | A specific sequence of SAVEPOINT commands (sub-transactions) combined with a DELETE query caused an FSCK failure. Therefore, deleted rows may have reappeared. |
4.1.1 | 16260 | A CTAS statement run inside a stored procedure caused Postgres to crash. |
4.1.1 | 16095 | Because of a timeout problem, replication failed with the following error: Found restore in error state. Aborting. Reason: Abandoned due to client inactivity |
4.1.1 | 16068 | Garbage 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.1 | 15465 | Replication 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