8.2.1.x补丁新增功能及解决问题
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_mainentance_mode无法终止业务语句 |
扩容重分布阶段,限制为xc_mainentance_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
类别 |
功能或问题描述 |
问题原因 |
问题出现版本 |
修复建议 |
---|---|---|---|---|
新增功能 |
无 |
- |
- |
- |
解决问题 |
集群hang检测触发集群切换。 |
信号重构前线程之前主要使用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及以下版本 |