8.2.1.x补丁新增功能及解决问题
8.2.1.259
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | 补丁升级后集群状态显示cm_server实例状态down | cm_server多线程交互时概率出现报文乱序导致core dump，且与cm_server交互的cm_agent数越多，cm_server主线程出现报文乱序的概率越高。 | 8.2.1.x | 升级到8.2.1.259补丁。 |
8.2.1.258
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | pg_get_raw_viewdef支持记录原始视图定义SQL。 | 在使用数据库时，需要获取创建视图时的原始SQL语句。在查询视图定义时能够直接返回原始的、易于理解的创建语句。 新增函数pg_get_raw_viewdef(viewname text)，为视图获取完整的原始视图创建语句，包含/**/格式的注释。 | - | - |
同一台x8000代理能同时处理多套集群的备份/恢复任务。 | 当前x8000下发备份、恢复任务时，会动态挂载不同的存储设备，DWS通过xbsa协议向x8000写入备份集时不会携带对应的任务标识，所以x8000在处理写入xbsa访问请求时无法确认应访问哪套挂载的存储设备。 | - | - | |
解决问题 | 管理面版本适配java17，udstool.jar用java17版本编译，用户自定义函数udf未适配java17，导致java udf功能不可用。 | 当前gs_extend_library调用内核中udstools.py文件，该文件调用管理面udstool.jar实现部署jar包，功能上受到管理面java版本影响，因此解耦到内核。 | 8.2.1.x/9.1.0.x | 升级到8.2.1.258补丁。 |
DWS涉及CVE-2024-10976漏洞需修复。 | 对行安全策略表的追踪不完整，导致重新使用的查询能够查看或更改非预期的行。这意味着，在使用特定角色的情况下，可能会应用不正确的策略，即一个查询最初在一个角色下计划，结果却在其他角色下执行。这可能会允许用户执行被禁止的读取和修改操作。 | 8.1.3.x/8.2.1.x | ||
集群在网卡异常产生告警，后续集群业务发生阻塞，重试依然失败，重启网卡后恢复。 | 某业务网卡驱动异常，导致bond0网卡偶现某个物理网卡down，网络情况异常，业务阻塞，重启网络服务可恢复。 | 8.2.1.x | ||
集群在网卡异常产生告警，集群业务发生阻塞，重试失败。 | 系统在建立连接时可能使用了旧版本的配置信息，导致连接过程中的等待机制无法正常唤醒，从而阻塞了连接。 | 8.2.1.x | ||
per-database共享内存未及时释放。 | 当建列存的Volatile临时表，在辅助表上有建立索引，索引的Pgstat信息在表删除后无法清理。 | 8.2.1.x | ||
Having子句使用select定义的别名出现结果集问题。 | 在Having子句的条件中，当聚集函数的别名与表中的列名相同时，系统预期会使用聚集函数的别名。然而，当前DWS默认使用列名，这与Oracle的行为存在差异。在Oracle兼容模式下，结果集可能不符合预期。 | 8.2.1.x | ||
修复Rough check场景下，多条重复IN条件导致的查询结果集非预期的问题。 | 多条重复的IN条件在下推到DN时，条件归约过程中，将DN编号计算错误，造成条件选择错误，引起结果集非预期的问题。 | 8.2.1.255 | ||
升级过程中涉及修改系统函数trunc(), 在用户生产环境中有部分用户表依赖该函数，由于依赖系统函数的对象未解耦导致升级失败。 | 用户创建依赖于trunc()函数的表。在升级时针对依赖于系统函数的业务表，不允许进行cascade删除，导致升级失败。 | 8.2.1.x | ||
INSERT分区表偶发报错：inserted partition key does not map to any table partition | 插入数据时找不到所属分区。 | 8.2.1.x | ||
表数据中特殊字符导致在ANALYZE时报错：malformed array literal | 在字符集GBK的数据库中，如果array数组中包含“\”字符时，系统未计算该字符长度，导致字符计算错误。 | 8.2.1.x | ||
细粒度恢复失败，rch文件中某个record的数据长度与实际压缩数据长度不一致导致恢复时报错。 | 集群级备份涉及 DROP DATABASE 操作时，rch 文件中会记录 HEAD+DATABASE 路径。当使用集群级备份集进行细粒度恢复时，如果读取到 head 类型为 DROP DATABASE 操作，则会直接跳过后续操作，导致 DATABASE 路径未被读取，从而造成后续 rch 文件错位。 | 8.2.1.x | ||
基于集群级带细粒度参数增量备份集进行表级恢复，导致少量CU页面未备份引起增量恢复失败的问题。 | 在进行增量备份时，系统会读取cbm以查询每个relfilenode的增量信息，并根据这些信息备份相应的增量数据。目前，系统仅在开始备份某个relfilenode的增量数据时记录一次fine_file_list信息。如果在备份过程中，rch文件发生切换，fine_file_list也会随之切换，但新的fine_file_list文件中不会记录该relfilenode的信息，这可能导致恢复时部分增量数据的丢失。 | 8.2.1.x |
8.2.1.256
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | 反解析语句有误导致视图rebuild失败报错。 | 视图反解析时错将nvl函数解析为coalesce函数，导致类型转换丢失，视图重建操作失败。 | 8.2.1 | 升级到8.2.1.256补丁。 |
扩容过程中表重分布涉及跨逻辑集群时会导致执行计划跳变。 | 默认情况下expected_computing_nodegroup =bind，若当前会话的用户是逻辑集群用户时，系统会将计算Node Group设置为与该用户关联的逻辑集群的Node Group，扩容期间如果表已分布到新的Node Group，这可能会导致执行计划的变化。 | 8.1.3 | ||
匿名块内创建表指定不同的逻辑集群，出现元数据错乱。 | 创建表时，部分数据定义的操作在执行过程中，因为内存上下文切换存在问题，可能导致操作偶发异常。 | 8.2.1 | ||
用户级used_spill_space内存堆积不释放。 | 语句执行回滚过程中如果存在用户切换，回滚事务会切换到之前的用户，再根据之前用户OID相关的资源进行计数，导致计数结果不准确。 | 8.1.3 | ||
关闭auto vacuum后，auto vacuum线程一直阻塞在同一个数据库。 | auto vacuum关闭后仅清理系统表，但当前业务中很多预置表不是系统表，或者业务库中业务表不会进行自动清理，导致数据库无法推进frozenxid，在forcefreeze时只能循环清理一个库，影响性能。 | 8.1.3 | ||
VACUUM FULL操作耗时长。 | VACUUM FULL每次执行完后都要扫描一遍PG_CLASS，再更新PG_DATABASE的datfrozenxid64字段，当PG_CLASS表过大时，会导致性能瓶颈。 | 9.1.1 | ||
修改资源管理参数未生效。 | 如果当前分配的CPU比较离散，则记录CPU信息的字符串就会比较长，此时如果再次增加CPU分配，会造成字符串超出定义的64长度，越界后字符串会变为空。设置CPU的分配字符串为空后，获取的CPU个数为1个，最终出现配置失败但未报错的情况。 | 8.2.1 | ||
历史TopSQL存储过程子语句stmt_type字段显示异常。 | 存储过程子语句在生成查询计划时先执行了SQL函数，查询计划和类型记录的是SQL函数，记录出现错误。 | 8.2.1 | ||
UDF进程无响应。 | 用户自定义函数（UDF）进程通过fork方式生成，如果父进程执行的函数持锁，子进程中的锁不会被释放，导致写日志时发生堵塞。 | 8.2.1 | ||
单表ANALYZE设置session级debug参数导致日志数据量大。 | ANALYZE在采集样本时，当零CU或常量CU很多时，会导致日志数据量大。 | 8.2.1 | ||
用户存储过程内创建临时表报错relation xxx already exists。 | 在存储过程或PBE中使用CREATE TABLE LIKE创建新表时，内部会将语句拆分为建表和插入语句分开执行。语义分析阶段会进行建表，并生成插入计划。在执行时，会检查计划缓存的有效性，若计划缓存无效，会尝试重新执行CREATE TABLE LIKE，但由于目标表已经存在，会导致错误。 | 8.2.1 | ||
text格式外表支持使用NULL填充不存在字段。 | 对于text/csv格式的外表，参数fill_missing_fields的设置，不支持多列缺失的场景。 | 9.1.1 | ||
大集群混合负载场景业务SQL偶现劣化。 | libcomm send proxy线程在空闲期会遍历所有与其他DN的连接进行检查，单次检查 1ms，在大集群上遍历100+连接，会耗时100ms以上，可能阻塞下一个报文的发送。 | 8.2.1 | ||
高并发行存copy入库导致CN所在节点CPU高，性能下降。 | 开启数据页通道后，需要在生成commit或回滚xlog前，将shared buffer中的脏页都被写入磁盘，避免DN异常重启时数据页面无法恢复。虽然CN上没有批量插入操作，但系统仍会遍历shared buffer，导致不必要的CPU资源占用。 | 8.1.3 | ||
备份和细粒度容灾加固。 | 细粒度容灾与备份与周边交互未正确适配。 | 8.2.1 |
8.2.1.255
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | 默认关闭LLVM。 | LLVM编译代码产生的mmap/munmap会对mmap写锁，阻塞进程级的page fault读锁。 | 8.2.1 | 升级到8.2.1.255补丁。 |
GDS导出产生大量乱码字符。 | 在GDS对一行文本进行字段拆分时，解析过程逐字符进行，并将 0x5C作为具有特殊含义的转义字符（即反斜杠）进行处理。因此，当字段末尾出现''时，该字段会被错误地舍弃。在 gb18030_2022编码中，0x815C是一个完整的双字节字符，但由于转义字符的优先级高于普通字符，该字符在解析过程中被错误拆分，导致仅保留单字节部分 0x81，而丢失了另一字节，从而破坏了字符完整性。 | 8.1.3 | ||
使用外表导入数据时，DN节点频繁发生故障。 | gc_fdw 生成的con的sock是直接赋值的，未使用dup操作。在接收数据时关闭了一次连接，而在事务中断时又进行了第二次关闭，从而导致 double-close问题。 | 8.1.3 | ||
优化视图information_schema.columns定义。 | 优化视图information_schema.columns的定义，让视图查询尽量走indexscan，从而提升效率。 | 8.1.3 | ||
含有脱敏策略的表修改字段长度报错cannot alter type of a column used in a redaction policy | 由于存在脱敏策略的表，在修改表定义时，系统会强制校验脱敏列的类型一致性，导致存在策略依赖而无法修改。 | 8.1.3 | ||
用户登录某CN节点输错密码被锁后，还能在其他CN节点登录。 | 用户信息在当前CN节点锁定后，该信息存在pg_user_status系统表中，但锁定信息没有同步到其他CN节点。 | 8.1.3 | ||
使用cm_ctl命令无法查询集群状态。 | cm_ctl与cm_server建连后，由于处理节点过多，cm_server处理线程超时。 | 8.2.1 | ||
支持Hive表容灾。 | Hive表备份恢复或容灾保护后，表路径下存在快照，无法直接删除表路径。 | 8.2.1 | ||
执行不区分大小写排序时报错。 | 执行不区分大小写排序过程中，系统会先转成GB18030编码，再进行排序，转换编码后出现生僻字，该生僻字不在GB18030中，而在GB18030-2022，导致排序失败，需要调整排序转换编码范围。 | 8.2.1 | ||
重建表去除大小写敏感属性（case_insensitive）后，对依赖表的视图进行CREATE OR REPLACE VIEW操作，视图上大小写敏感依然存在，导致结果集异常。 | 视图解耦打开，执行CREATE OR REPLACE VIEW操作时系统未检查attcollation字段是否相同，视图在pg_attribute中相关字段的collate case_insensitive信息未消除，导致查询结果异常。 | 8.2.1 | ||
修复plan management问题。 | - | 8.2.1 |
8.2.1.251
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | 在集群扩容过程中，由于存在失效视图无法删除，导致扩容失败。 | 集群存在失效视图无法删除，在扩容阶段执行删除视图操作时，因删除失效视图失败进而导致扩容操作失败。 | 8.2.1.225 | 升级到8.2.1.251补丁。 |
查询锁视图pgxc_lockwait_detail磁盘I/O占用较高，影响系统性能。 | 并发场景下，当前版本的实现方式是pgxc_lockwait_detail从各个节点获取全量锁信息到执行CN，然后在执行CN上关联查询锁等待关系，计算下盘量大资源消耗高。 | 8.1.3 | ||
JSON数据入库字段过长导致报错。 | 使用JSON格式外表，当JSON包含过多的对象（超过1024）时，由于内存初始化不正确导致JSON解析异常进而查询报错。 | 8.2.1 | ||
列存表中VACUUM和DELETE操作并发时报错CU Delete bitmap is missing。 | 如果存在未提交的事务ID（xid）早于当前快照（snapshot）记录的最小活跃事务（xmin），可能导致快照在判断数据可见性时出现逻辑错误，从而引发系统异常。 | 9.1.0 | ||
解决HashJoin转Nestloop执行后的报错问题。 | 在对下盘的分区数据进行HashJoin操作时，前面的分区没有转成NestLoop方式执行，导致传递给子计划（SubPlan）的数据是3列，后面的分区转成Nestloop执行，传递给SubPlan的数据增加到4列（条件中有表达式会增加一列保存哈希值），前后分区传递的列数不一致，导致访问越界，引发错误。 | 8.2.1 | ||
try_cast函数导致DN多实例异常。 | 当转换的数据与目标类型不兼容时，会进入错误处理的内存上下文中，try_cast结束时未回切到正确的内存上下文，可能导致运行时数据被提前回收，从而导致DN多实例异常。 | 8.2.1 | ||
statement timeout日志打印异常，start time和alarm time时间不正确。 | 根据C标准section 7.16p3，尽管C允许va_list作为参数ap传递给另一个函数，但一旦函数中调用va_arg，则函数中的ap值是不确定的；C也允许使用va_list指针做参数传递给另一个函数，这样做，调用va_arg时就会通过指针去访问原始列表。 | 8.2.1 | ||
节点进程数暴增，节点上DN实例线程无法退出，业务执行慢，主备未切换。 | OS异常，进程数暴增，业务执行慢，现有机制无法识别。 | 8.1.3 | ||
同一事务内INSERT SELECT表A，再ALTER表A报错表不存在。 | 针对relation not exist场景，增加debug日志。 | 8.2.1 | ||
业务数据库连接出现异常，空间管控内存占用高，低概率导致业务报错。 | 在处理空间管控消息时，系统会对数据库连接失败进行记录。如果某个数据库连续20次连接失败，系统将不再尝试连接该数据库进行后续处理，这可能导致空间管控消息堆积。 | 8.2.1 | ||
ANALYZE内存估算偏差大，导致CCN异常排队。 | ANALYZE执行前基于列的平均宽度（avgwidth）估算内存，宽列会导致内存估算偏大。实际ANALYZE过程中：
因此，对于宽度超过1024字节的数据，行存和列存实际上都没有读取数据，需要调整内存估算算法。 | 8.1.3 | ||
动态配置文件为空，cm_server无法启动。 |
| 8.1.3 | ||
处理列存和行存的join操作时，大表全量重分布和增量充分布超时。 | 在处理列存和行存的join操作时，查询优化器会执行一系列检查。在其中一个检查步骤中，系统发现tid类型不被支持，导致操作失败。 | 8.2.1 | ||
重分布结束后，部分表执行业务报错: Unsupported xxx command during online expansion。 | 在重分布流程中，加锁时使用表名拼接lock语句，加锁成功后则继续重分布，但是存在如下场景导致加锁的表非原表，导致后续流程报错： 在重分布进程启动后，获取到所有需要重分布的表，如果某张表A在重分布开始前，执行了rename重命名为B，且创建了一张和原表同名的新表A'(新表分布在新NodeGroup中)，会漏重分布重命名后的表B，并将A'，认为是原表进行重分布，最后A'重分布流程会在ADD Node时报错，提示表已经存在于新节点。 | 8.2.1 | ||
有脱敏策略的分区表，重分布过程中偶现死锁导致重分布失败。 | 在重分布阶段，需要将基表中数据插入到名叫'data_redis'的schema的临时表中。但当基表为带有脱敏策略的分区表时，将各个分区的数据并发插入同一张临时表时，会在临时表上基于脱敏策略继承机制创建脱敏策略，导致死锁、重分布失败。 | 8.1.3 | ||
使用DBeaver等客户端执行SQL，将查询作业使用的资源信息保存到资源监控历史视图（TopSQL）时，出现内存泄露问题。 |
| 8.1.3 | ||
相同的unique_sql_id对应不同业务SQL，影响基于unique_sql_id进行业务分析。 | PBE场景下多次执行SQL，没有重置UniqueSqlId并生成新的UniqueSqlId，然后使用空串来生成UniqueSqlId值为2817148525，导致不同的SQL都为这个值。 | 8.2.1 | ||
新分析集群参数同步异常，迁移启动后有大量参数不一致导致启动失败 老集群残留搬迁过程文件，通过搬迁过程传到新集群后，影响新集群对于配置文件的处理，导致参数异常修改。 | 集群A上做过集群恢复，备份集的postgresql.conf会被恢复成postgresql.conf.backup，且postgresql.conf.backup文件残留。当集群A后面又作为主集群同步数据到集群B时，集群A的postgresql.conf与postgresql.conf.backup都会备份，在两个文件恢复时，postgresql.conf先恢复成postgresql.conf.backup，然后残留的postgresql.conf.backup也恢复为postgresql.conf.backup并将由postgresql.conf恢复的postgresql.conf.backup覆盖掉，导致集群B出现A的残留postgresql.conf.backup中的GUC。 | 8.1.3 | ||
执行UPDATE操作报错The inserted partition key is not mapped to the specified '%s' partition | 按分区收集统计信息的表上执行UPDATE，因分区计算错误，导致UPDATE场景报分区匹配错误。 | 8.2.1 | ||
分布列查询报错value too long for type nvarchar2(20) | 当数据库表的分布键使用nvarchar2类型时，如果查询条件的字符串长度超过了该列定义的最大长度，系统会报错。 | 8.1.3 |
8.2.1.236
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 实现DWS自查找依赖的能力：新安装和升级DWS集群时，实现不借助LD_LIBRARY_PATH环境变量，也能自行查找到依赖的动态库的能力。 | - | - | - |
使用DWS建外表时支持date类型。 | - | - | - | |
TD兼容模式下使用GDS外表导入数据，当外表数据为多个空格且该值对应的插入目标表的字段数据类型为整型时，空格被解析为0，然后插入目标表。用户需要解析为NULL。 | - | - | - | |
解决问题 | 递归查询中出现in子句时，当递归查询被父查询多次引用时，出现异常。 | 当存在inlist参数的递归查询被多次引用时，系统会复制多个执行计划副本。由于每个副本的数据指针分散到不同存储位置，导致原本通过地址比对的关键判断失效，进而产生执行流程错误，最终引发集群故障。 | 8.2.1 | 升级到8.2.1.236补丁。 |
JDBC通过preparedStatement执行语句时，如果查询计划失效(例如涉及的表发生DDL)，会导致相同的语句unique_sql_id不唯一。 | 通过JDBC执行SQL走PBE协议，阶段分别是解析语句（P）、绑定参数（B）、执行语句（E）。在绑定参数阶段（B）如果发现查询计划失效，会重新生成查询计划并再次生成unique_sql_id，再次生成时传入的长度是0，生成了2817148525这个unique_sql_id，执行语句（E）将这个错误的ID保存到了TopSQL里。 | 8.2.1 | ||
VACUUM FULL之后get_col_file_vacuum_info函数查询数值未更新。 | 查询该函数时，当缓存中存在该表信息时，不会刷新缓存中的信息，导致rewritten_file_num数值未变化。 | 8.2.1 | ||
show-progress命令中缺失RTO时间估算，不便于观测。 | 集群容灾show-progress命令中缺少RTO时间估算。 | 8.2.1 | ||
高并发、大流量查询业务持续执行时，业务低概率报错内存申请错误。 | 并发查询时，如果实例使用的通信内存超过comm_usable_memory，通信库临时内存（高于comm_usable_memory部分）复用率低，且释放速度较慢，导致通信库临时内存较大，集群运行可用内存不足，出现内存不足报错。 | 8.2.1 | ||
ORC外表导入时，若外表字段长度超过导入目标表对应字段的长度限制，执行报错。 | ORC外表把VARCHAR类型当作text处理，未进行长度校验，当导入目标表时，出现长度校验失败的报错。 | 8.1.1.100 | ||
使用insert overwrite将数据从互联互通外表写入内表后，内表查询异常。 | insert overwrite过程中，源表为互联互通外表时，临时表和目标表的映射关系丢失。 | 8.1.3 | ||
集群实例发生未知原因重启。 | NTP监控脚本有极低概率会误终止gaussdb进程。 | 8.2.1 | ||
parquet外表查询时，如果过滤条件字段为string类型且字段长度大于1024字节时，查询报错。 | parquet格式外表的string字段的过滤条件处理时，如果string类型字段长度大于1024字节（默认缓冲区的长度）时，会出现内存拷贝失败，导致执行报错。 | 8.3.0 | ||
查询语句中调用自定义plpgsql函数时性能差。 | plpgsql函数每次执行之后都会触发ResourceOwner的清理操作，此逻辑执行代价比较高，导致查询语句性能差。 | 8.2.1.225 | ||
使用JDBC的CN负载均衡场景下，url中会指定多个CN的IP信息，当某个CN故障导致无法连接时，可能会出现JDBC连接请求报错。 | JDBC的CN负载均衡场景下，会缓存所有连接的url信息；当某个CN故障时，其对应的缓存信息若没有及时清除，当其存在复用情况时导致连接报错。 | 8.2.1 | ||
ARM平台下执行分布式DML语句时，低概率出现语句挂起。 | 在ARM平台下，含stream算子的分布式执行计划底层依赖的无锁队列中的标志位，在更新原子操作的内存序号时发生了乱序，导致执行挂起。 | 8.3.0 |
8.2.1.230
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 细粒度备份恢复支持在线DDL：支持在细粒度备份过程期间对表进行DDL操作。 | - | - | - |
细粒度表级恢复支持恢复至异构集群：细粒度表级恢复不再受目标集群必须与恢复集群的拓扑结构一致的约束。 | - | - | - | |
细粒度备份恢复支持跨版本恢复。 | - | - | - | |
集群级物理细粒度备份以及schema级物理细粒度备份支持备份权限与注释。 | - | - | - | |
在线扩容重分布阶段支持动态调整优先级。 | - | - | - | |
解决问题 | Catchup与DDL业务锁冲突，Catchup持续长时间不结束。 | 存储过程中如果存在DDL操作，在事务提交前，存在几率导致Catchup无法结束，报锁超时。 | 8.0.x | 升级到8.2.1.230版本。 |
With recursive语句长时间运行未结束。 | ARM环境中线程信息同步问题，导致变量更新不同步。 | 8.1.3.322 | ||
gs_wlm_readjust_relfilenode_size_table内存占用大 | pg_relfilenode_size表完全加载到内存中，占用内存过大。 | 8.1.3.323 | ||
集群长时间运行TopMemoryContext内存不断累积增大。 | stream线程在返回线程池时并不会立即释放内存，导致长时间运行时TopMemoryContext内存不断累积增大。 | 8.2.1.22 | ||
SQL语句执行异常终止，报错：canceling statement due to coordinator request. | 带有stream算子语句执行时报错，向子stream线程发出cancel，此时stream线程已经回到了stream线程池。下一条query语句复用了该stream线程，因为缺少对query id的强一致校验，响应了上一条语句残留的信号，导致语句被异常终止。 | 8.1.3.110 | ||
schema空间查询，usedspace大于permspace。 | 在判断schema空间上限时，采用已用空间对比空间上限，导致实际使用会超出上限。 | 8.2.1.230以前版本 | ||
参数max_files_per_node设置为-1业务执行失败。 | SQL执行过程中在创建stream线程阶段，会先读取配置参数max_files_per_node值，默认值为50000， 然后报错句柄超上限。 因此即使设置了guc的值为-1，但是guc的值未生效。 | 8.1.3.321 | ||
SQL执行报错：Stream plan check failed. Execution datanodes list of stream node mismatch in parent node. | 生成计划时下层的计划节点复用了上层的计划节点，导致修改一个计划节点时修改了所有的节点。 | 8.2.1.230以前版本 | ||
扩容重分布阶段，不开启xc_maintenance_mode无法终止业务语句 | 扩容重分布阶段，限制为xc_maintenance_mode开启才能执行pg_cancel_query/ pg_cancel_backend等函数，导致重分布阶段，用户业务语句无法成功杀语句。 | 8.2.1.230以前版本 |
8.2.1.225
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | GDS非法字符替换异常 | GDS非法字符替换为特殊字符（�）时出现异常，替换过程中由于字符串长度发生变化，在后续处理时仍使用原长度，导致部分字符被截断，无法正确替换。 | 8.2.1.225以前版本 | 升级到8.2.1.225版本。 |
并发压测过程中，概率性出现gather性能劣化 | 当语句中存在stream算子时，在DN上会根据计划生成多个stream线程，其中最顶层的父线程为topConsumer线程，负责将子stream线程的数据整合并发送往CN。当语句执行结束时，topConsumer线程必须等待所有的子stream线程退出后才可以执行stream线程组的清理动作。 | 8.2.1.225以前版本 |
8.2.1.223
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 无 | - | - | - |
解决问题 | 集群异常检测触发集群切换。 | 信号重构前线程之前主要使用SIGUSR2这个不可靠信号用于IPC，重构后使用了可靠信号34、35两个信号。 在信号发送数量巨大的情况下，可靠信号的使用加大了timer创建失败的概率。 | 8.2.1.220 | 升级到8.2.1.223版本。 |
业务并发pgxc_cgroup_reload_conf出现core：GsCgroupIsClass。 | 指针访问未加锁，当reload函数重新加载该访问变量后，指针被修改，导致访问到野指针，导致core问题。 | 8.2.1.220 | ||
gs_table_distribution函数获取的表大小与真实值差距较大。 | 在分批读取pg_refilenode_size系统表的数据后进行计算时，当前批次计算得到的表大小会重复累加前面几批计算得到的表大小，导致gs_table_distribution函数获取的表大小与真实值差距较大。 | 8.2.1.220 | ||
执行SQL语句报错：Could not open file "pg_clog/000000000075"。 | 列存表进行VACUUM FULL后可能提前回收clog，导致主备切换后进行ANALYZE时无法访问clog文件。 | 8.2.1.119 | ||
修复临时变量未初始化导致的freememory大负数问题。 | 临时变量声明后，未赋值导致参数值非预期，后续再去扣减内存，出现大负数。 | 8.2.1.220 | ||
智能运维配置VACUUM FULL后，VACUUM FULL实际执行时间超过配置的时间区间。 | 调度器kill VACUUM FULL任务时插入了新的running任务，导致kill没有执行干净。 | 8.1.3.x |
8.2.1.220
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 |
| - | - | - |
解决问题 | SQL执行性能不稳定，查询很慢，查询pgxc_thread_wait_status状态长时间是HashJoin - nestloop。 | 执行nestloop时每组partition行数有近10000，由于数据都不一样，但是仍继续执行nestloop。 | 8.1.3.300 | 升级到8.2.1.220版本。 |
数据库下有大量对象，普通用户查询该数据下的对象时，出现性能慢，且占用大量内存。 | 性能慢主要因为：列存模式下，有大量的internal_mask选项的表，导致权限校验函数被无效调用；列权限校验耗时长，导致计算量大。 | 8.2.1.119以前版本 | ||
表达式过多的场景，LLVM编译时间长导致CPU高。 | 启用LLVM时，在表达式过多的场景下，执行需要几个小时，关闭LLVM后只需十几分钟。当表达式个数多于1000时，会产生编译时间指数级递增的问题。 | 8.1.3.320 | ||
业务查询游标每次fetch2000笔数据，每次获取都比上次估算内存大了24MB，总数据量2000W条，查询无法执行。 | PBE场景会复用之前生成的计划，导致估算内存每次递增一个固定值，估算内存不断膨胀导致CCN排队。 | 8.1.3.323 | ||
JSON类型查询内存泄露，导致重分布占用大量内存。 | 在jsonb的out函数中存在内存未释放问题，数据量大时出现堆积造成使用内存高。 | 8.1.3.x | ||
执行客户业务sql，只要执行select * from with子句就会出现CN core。 | ProjectionPushdown更新了rte，但是未基于新的rte更新var，导致后面处理quals的时候core。 | 8.1.3.323 | ||
DELETE语句WHERE条件数超过上限导致溢出。 | DELETE语句WHERE条件数超过int16上限（32767）导致溢出，越界产生core。 | 8.1.2.x | ||
扩容时重新拉起重分布进程，生成表清单的时候，卡住1小时以上。 | 生成表清单语句是查询系统表后插入pgxc_redistb，pgxc_redistb是分布式表，查询系统表都是在CN上执行，再插入分布式表时每条记录都要执行一个INSERT INTO ... VALUES语句，如果表数量非常大会非常耗时。 | 8.1.3.110 | ||
主键冲突事务回滚导致CN内存泄漏。 |
| 8.2.0.103 | ||
count distinct和union all场景下，实际使用内存大量超过估算内存。 | 多分支串行执行场景只考虑了下层算子返回数据时的内存，未考虑下层算子实际执行过程中的内存，导致内存估算偏小。 | 8.1.3.321 | ||
重启集群后，只有首次使用SQL调试的会话连接可以正常进行SQL调试，其他会话连接无法正常调试。DataStudio调试SQL打断点不生效。 | 调度入口变量在与数据库断开连接后会被释放，后续为空指针，无法进入调试逻辑。 |
| ||
with recursive语句长时间运行未结束。 | ARM环境下线程信息同步问题，导致变量更新不同步。 | 8.1.3.323 | ||
执行INSERT OVERWRITE指定分区，会覆盖全表。 | PBE逻辑中拷贝计划信息时，没有拷贝INSERT OVERWRITE中的分区信息，导致最终对全表进行了FILENODE交换。 | 8.2.1.220以前版本 | ||
包含windowagg的子查询结果集异常。 | 生成bloomfilter过程中，没有考虑windowsagg，在join关联列非windowsagg分组列的场景下会减少分组数据，进而对窗口函数该分组的结果产生影响。 | 8.1.3.x | ||
业务出现大量内存不足报错，视图显示占用内存高的SQL均为VACUUM FULL操作。 | 分区表在对每个分区分别进行VACUUM FULL时，漏掉了一部分内存的释放操作，导致内存不断累加和膨胀，直至报错。 | 8.1.3.x | ||
逻辑集群执行重启超时。 | CM内部默认使用了10个ip，需要动态适配。 | 8.2.1.200 | ||
更新版本后出现大量Wait poll time out错误。 | LibcommCheckWaitPoll函数在传入-1时行为与预期不一致。 | 8.2.1.200 |
8.2.1.119
类别 | 功能或问题描述 | 问题原因 | 问题出现版本 | 修复建议 |
|---|---|---|---|---|
新增功能 | 窗口函数last_value支持ignore nulls功能，兼容Redshift。 | - | - | - |
解决问题 | 列存表使用try_cast函数报错。 | try_cast函数未适配向量化执行引擎，导致列存表执行时报错。 | 8.2.1.100及以下版本 | 升级到8.2.1.119。 |
重启集群后，insert过慢长时间无法结束。 | 重启集群后，insert时需要使用索引扫描全量数据而影响性能。 | 8.2.1.100及以下版本 | ||
CCN计数异常时，未触发校准机制，导致CCN排队加剧。 | CCN计数异常时，由于代码处理bug，未触发校准机制。 | 8.2.1.100及以下版本 | ||
JDBC中使用PBE协议插入数据，因主键冲突报错导致CN内存泄漏。 | 此场景下使用CN轻量化流程进行处理，事务结束后轻量化对象未释放造成内存堆积。 | 8.2.1.100及以下版本 | ||
SQL语句中设置了enable_stream_ctescan的GUC HINT，生成计划时CTE估算内存超阈值后，生成计划有误导致执行失败。 | SQL语句中设置了enable_stream_ctescan的GUC HINT后，生成计划时CTE估算内存超阈值后，回退成非share scan的计划，但由于包含Hint回退不彻底，生成的计划包含错误节点，导致后续执行失败。 | 8.2.1.100及以下版本 | ||
备份metadata元数据到OBS上超过64MB时，恢复时概率性解压元数据报错，导致恢复失败。 | 备份metadata元数据超过64MB时，从OBS下载需要分段下载，下载最后一段buffers由于代码漏洞导致被丢弃，下载的metadata损坏，导致无法解压。 | 8.2.1.100及以下版本 | ||
hstore delta表analyze采样占用内存高。 | hstore delta表analyze采样时，delta合并I记录占用内存较多，需要即时释放toast数据及delta数据反序列化占用的空间。 | 8.2.1.100及以下版本 | ||
CTE查询中有volatile函数，且只被引用一次时，不能下推，导致查询性能差。 | 821版本增加CTE查询中有volatile函数时不能下推的约束，但针对CTE只被引用一次的场景，需要放开约束，支持其下推。 | 8.2.1.100及以下版本 | ||
复杂查询的临时文件下盘，xfs系统预占空间过大，下盘文件多时导致集群只读。 | 复杂查询的临时文件下盘，xfs系统每个下盘文件预占16MB，下盘文件多时导致集群只读，需要减少下盘文件预占磁盘量。 | 8.2.1.100及以下版本 |
