Release date: May 26, 2022
Improvements
For window functions in which the frame is set to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, if the partition involved in a calculation is large, StarRocks caches all data of the partition before it performs the calculation. In this situation, a large number of memory resources are consumed. StarRocks has been optimized not to cache all data of the partition in this situation. [5829](https://github.com/StarRocks/starrocks/issues/5829)
Bug Fixes
The following bugs are fixed:
- When data is loaded into a table that uses the Primary Key model, data processing errors may occur if the creation time of each data version stored in the system does not monotonically increase due to reasons such as backward-moved system time and related unknown bugs. Such data processing errors cause backends (BEs) to stop. [6046](https://github.com/StarRocks/starrocks/issues/6046)
- Some graphical user interface (GUI) tools automatically configure the set_sql_limit variable. As a result, the SQL statement ORDER BY LIMIT is ignored, and consequently an incorrect number of rows are returned for queries. [5966](https://github.com/StarRocks/starrocks/issues/5966)
- If the DROP SCHEMA statement is executed on a database, the database is forcibly deleted and cannot be restored. [6201](https://github.com/StarRocks/starrocks/issues/6201)
- When JSON-formatted data is loaded, BEs stop if the data contains JSON format errors. For example, key-value pairs are not separated by commas (,). [6098](https://github.com/StarRocks/starrocks/issues/6098)
- When a large amount of data is being loaded in a highly concurrent manner, tasks that are run to write data to disks are piled up on BEs. In this situation, the BEs may stop. [3877](https://github.com/StarRocks/starrocks/issues/3877)
- StarRocks estimates the amount of memory that is required before it performs a schema change on a table. If the table contains a large number of STRING fields, the memory estimation result may be inaccurate. In this situation, if the estimated amount of memory that is required exceeds the maximum memory that is allowed for a single schema change operation, schema change operations that are supposed to be properly run encounter errors. [6322](https://github.com/StarRocks/starrocks/issues/6322)
- After a schema change is performed on a table that uses the Primary Key model, a "duplicate key xxx" error may occur when data is loaded into that table. [5878](https://github.com/StarRocks/starrocks/issues/5878)
- If low-cardinality optimization is performed during Shuffle Join operations, partitioning errors may occur. [4890](https://github.com/StarRocks/starrocks/issues/4890)
- If a colocation group (CG) contains a large number of tables and data is frequently loaded into the tables, the CG may not be able to stay in the stable state. In this case, the JOIN statement does not support Colocate Join operations. StarRocks has been optimized to wait for a little longer during data loading. This way, the integrity of the tablet replicas to which data is loaded can be maximized.
**Full Changelog**: https://github.com/StarRocks/starrocks/compare/2.1.6...2.1.7
Thanks to
Astralidea, HangyuanLiu, Linkerist, Youngwb, chaoyli, decster, dirtysalt, gengjun-git, meegoo, rickif, sevev, stdpain, trueeyu, xiaoyong-z