8.2.1.x补丁新增功能及解决问题

新增功能

无

-

-

-

解决问题

集群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

新增功能

• MERGE INTO支持指定分区。
• 支持plan management。
• GDS导出外表支持容错参数compatible_illegal_chars。
• 窗口函数last_value 支持ignore nulls功能。

-

-

-

解决问题

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内存泄漏。

1. JDBC中使用PBE协议插入数据走CN轻量化，因主键冲突等原因执行报错。
2. 一个事务内包含多个交叉CN轻量化查询，或者JDBC发送的unnamed statement，执行前会将全局的LightProxy对象保存到Portal上，事务结束场景LightProxy对象未释放造成内存堆积。
3. 表现为CN的pv_session_memory_detail视图中查询到大量CachedPlanQuery内存上下文。

8.2.0.103

count distinct和union all场景下，实际使用内存大量超过估算内存。

多分支串行执行场景只考虑了下层算子返回数据时的内存，未考虑下层算子实际执行过程中的内存，导致内存估算偏小。

8.1.3.321

重启集群后，只有首次使用SQL调试的会话连接可以正常进行SQL调试，其他会话连接无法正常调试。DataStudio调试SQL打断点不生效。

调度入口变量在与数据库断开连接后会被释放，后续为空指针，无法进入调试逻辑。

• 8.1.1.x
• 8.1.3.x

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

新增功能

窗口函数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及以下版本