关键缺陷通知

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P1

创建含有空格、特殊字符和大小写的复杂表名的表时，实例短暂重启。

在从系统表获取表的table property时状态错误，导致实例coredump。

• V4.1.6

• V4.0.23

• V4.1.7

• V4.0.24

• 升级至最新版本。

P2

ai_gen与to_file联用时会报错。

function ai_gen(text, text, file, bytea) does not exist

ai_gen与to_file联用时，类型转换错误，导致函数报错。

• V4.1.5

• V4.0.21

• V4.1.6

• V4.0.22

• 升级至最新版本。

P1

如果某计算组没有加载源表所在Table Group，在使用该计算组通过轻量级连接模式（Flink源表参数connection.fixed.enabled为开启或根据实例版本默认开启状态）消费源表Binlog后，该实例会持续无法新建连接。

在通过轻量级连接模式消费Binlog的初始化阶段，由于当前计算组未加载Table Group，请求会自动重试。重试期间错误持有全局锁，导致无法响应新建连接。

• V3.1.13

• V3.2.10

• V4.0.0

• V4.0.8

• 升级至最新版本。

• 若实例连接数充裕，将源表connection.fixed.enabled设为false，临时绕过此问题。

P1

含有双流Join的增量动态表首次刷新或REFRESH OVERWRITE时有概率报错。

ERROR: hos_exception: Internal error: status { code: OPERATION_INVALID_ARGUMENT message: "duplicate key value violates unique constraint...

如果定义中有基于双流Join结果的聚合，则可能导致聚合结果错误。

首次增量刷新有小概率会将短时间内已经被删除的数据计算进去，导致报错或者结果错误。

• V3.2.5

• V4.0.1

• V4.1.1

• V4.0.21

• V4.1.6

• 升级至最新版本。

P2

array_to_string函数在处理两个入参请求时，如果输入数据包含NULL值，则该NULL值将参与计算。这与PostgreSQL的行为不一致，预期应为NULL值不参与计算。

HQE引擎在处理该函数两个入参请求时，计算逻辑存在缺陷。

• V3.0.1

• V3.1.1

• V3.2.1

• V3.0.46

• V3.1.25

• V3.2.24

• 升级至最新版本。

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P2

在使用JOIN且执行引擎是PQE时，报错

ERROR: XX000: internal error: unmatched data row schema number

Join 和 PQE场景下，Join的输出列和PQE的输入列对不齐导致报错。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.33

• V3.2.24

• V4.0.13

• 改写SQL，避免使用PQE引擎执行。

• 升级至最新版本。

P2

使用了PQE引擎，执行了between计算，报错

ERROR: 0A000: ORCA failed to produce a plan : Operator BetweenAnd not supported

PQE引擎不支持between算子计算。

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.13

升级至最新版本。

P1

将timestamp作为segment key或者cluster key时，进行过滤会导致最终结果没有被过滤。

存储引擎在当前提取segment key有问题，导致数据未过滤。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.24

• V4.0.13

升级至最新版本。

P1

升级到V4.0后内存持续升高，且在没有任何查询时也没有下降和平稳的趋势。

V4.0 版本在 result cache 链路遇到dict array会发生内存泄露。

• V4.0.0

• V4.0.10

• 关闭开关，临时绕过该问题。

   select hg_admin_command('set_global_flag', 'enable_dict_array=false');

• 升级至最新版本。

P2

在CTE复用的情况下无法生成plan，报错

ORCA failed to produce a plan : No plan has been computed for required properties

由于QO未正确更新CTE计数，导致最终报错。

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.7

• 关闭开关，临时绕过该问题。

  ALTER DATABASE <database_name> set set hg_cte_strategy = 'inlining'; 

• 升级至最新版本。

P2

使用范围方式取数组元素报错，例如array_column[1:1]。

QO处理数组元素有问题，导致最终报错。

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.13

升级至最新版本。

P1

同时满足如下所有条件时，若Shard数大于bucket数，则PQE输出的数据不经过shuffle直接和另外一张同个Table Group的表的普通列存scan的结果做JOIN、UNION ALL 计算，有概率漏数据。

• 列存表走主键索引，触发 point seek

• 数据直接使用PQE计算

列存表使用主键索引的时候QO生成的计划里没有使用Gather算子，导致如果bucket数不等于shard数，一个bucket里有多个shard，pqe query 计算的shard_count/bucket_count的概率漏数据。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.10

升级至最新版本。

P2

• 当用户rebuild的表，表名含有大写字母又没有其他特殊字符时。rebuild报错，任务失败，progress里显示获取view失败。

• 当用户rebuild的表，列名含有大写字母又没有其他特殊字符时。rebuild报错，任务失败，progress里显示临时表缺列。

rebuild在老版本中并未考虑大小写的情况，所以导致失败。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.40

• V3.2.25

• V4.0.13

升级至最新版本。

P2

subquery中包含case when表达式时，报错如下：

ERROR: column "xxx" does not exist

查询优化器处理该场景时存在Bug，导致无法生成可用的查询计划。

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V4.1.0

• V3.0.53

• V3.1.41

• V3.2.25

• V4.0.14

• 关闭开关，临时绕过该问题。

  ALTER DATABASE <database_name> set hg_experimental_reuse_switch_case_expression =off;  

• 升级至最新版本。

P1

在Flink消费Hologres Binlog时，如果Flink作业中定义的源表（Source Table）仅包含Hologres物理表中的部分列，则消费的数据可能会出现非预期的空值。

Flink的Hologres Connector在处理消费Binlog部分列的场景时存在缺陷。

• Flink VVR 11.3或11.4，且Hologres版本为V4.0.1及以上。

• Flink VVR 11.3及11.4版本的热修复于2026年1月9日正式发布。

• 修复时间后重启Flink作业即可。

• 修复前，可在Flink源表的WITH参数中增加如下配置并重启作业：source.binlog.project-columns.enabled' = 'false'。

P1

已完成的Query可能未能正确清理，从而导致事务残留，进而造成表锁无法释放。

当前版本在部分已结束运行的Query的垃圾回收(GC)逻辑上存在缺陷，导致查询标识符（query_id）残留。

• V2.2.0及以下版本。

• V3.0.0

• V2.2.32

• V3.0.12

• 升级至最新版本。

• 使用如下SQL手动清理残留的query：

  SELECT pg_terminate_backend(pid) FROM hg_stat_activity WHERE query_id = <query_id>;

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P0

查询 DLF 的 Paimon Postpone 表时，会读取到已提交但尚未进行压缩的数据，从而导致主键表中出现主键重复的情况。

Hologres升级至V3.2.12版本后，Paimon SnapshotReader类的接口行为发生了变更：

• 旧版Paimon SDK：SnapshotReader在构造时，会自动为postpone表添加onlyReadRealBuckets选项。该选项确保只读取已完成Compaction的最终数据。

• 新版Paimon SDK：移除了上述自动添加逻辑。现在，使用者需要手动为SnapshotReader配置此选项，才能实现只读最终数据的行为。

• V3.2.12

• V4.0.0

• V3.2.24

• V4.0.11

• 升级至最新版本。

P1

在使用DLF外表时，当设置Paimon表的bucket_num=-2时，在涉及多表JOIN的场景中，由于生成的JOIN计划不正确，导致数据未能关联，从而造成查询结果的不准确。

当设置Paimon表的bucket_num=-2时，在涉及多表JOIN的场景中，由于生成的JOIN Plan不正确，导致数据未能有效关联，从而造成查询结果不准确。

• V3.2.0

• V4.0.0

• V3.2.21

• V4.0.8

• 关闭开关，临时绕过该问题，设置SQL如下：

  ALTER DATABASE <database_name> set hg_experimental_use_shard_info_in_hashed_dist_spec=off;  

• 升级至最新版本。

P1

在使用CTE表达式时，发现拆分执行与联合执行的结果存在差异。

在使用CTE表达式时，尽管在执行中间结果时出现了失败，但并未将该失败情况上报给FE，最终导致了结果的错误。

• V3.2.0

• V4.0.0

• V3.2.17

• V4.0.6

• 升级至最新版本。

P1

在用户具备相应权限的前提下，holgores.hg_query_log 和 hologres.hg_table_info 的查询结果为空。

holgores.hg_query_log 和 hologres.hg_table_info 数据未上报。

• V2.0.39

• V2.2.16

• V3.0.0

• V2.0.47

• V2.1.44

• V2.2.24

• V3.0.2

• V3.1.0

• V3.2.0

• V4.0.0

• 升级至最新版本。

P0

含有多流JOIN 的 Dynamic Table增量刷新时，当只有一条流有数据且数据有回撤时，刷新结果出错，结果和查询结果不一致。

在Dynamic Table进行增量刷新时，存在仅在单流回撤情况下未能正确处理的问题，导致应从结果表中删除的数据未被正确移除，从而造成结果表的错误。

• V4.0.1

• V4.0.9

• 首先对表数据进行修改，然后使用 refresh overwrite 修正已出现错误的数据，具体操作如下所示的两个 SQL：

  alter table xxx set (refresh_guc_hg_experimental_incremental_agg_insert_bulkload_batch_size = 1);
  refresh overwrite table xxx with (refresh_mode = 'incremental');

• 升级至最新版本。

P1

升级至V4.0版本后，出现了Worker OOM错误，相关报错信息类似：

1. 报错：ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

2. 报错：ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

为了在内存中缓存更多数据，V4.0版本对内存结构进行了优化。然而，新的内存结构在处理Decimal类型时存在缺陷，因此当包含Decimal列的表参与HashJoin时，可能会导致实例发生CoreDump。

• V4.0.0

V4.0.10

• 关闭查询内存优化，临时绕过该问题，SQL设置如下：

  select hg_admin_command('set_global_flag', 'enable_selection_vector=false');

• 升级至最新版本。

P1

查询 MaxCompute Append Delta Table 有数据的表时，查询返回为空。

受到 Split Cache 影响，导致查询结果为空。

• V4.0.0

V4.0.9

• 关闭 Split Cache，临时绕过该问题。

ALTER DATABASE <database_name> set hg_experimental_enable_maxcompute_sdk_splits_cache=off;

• 升级至最新版本。

P0

在V4.0版本中使用逻辑分区表，逻辑分区表包含主键并设置了clustering_key时，发现有主键数据重复。

V4.0 版本为了优化逻辑分区表的写入性能，支持多分区 Flush，在多分区 Flush 时，Cluster Index 的处理逻辑存在 Bug，导致写到盘古上的 AliORC 文件（列存内表的数据文件）内部的 Cluster Index可能有错，Cluster Index 错误可能导致数据存在但查不出来，最终导致在写入更新场景下，可能会认为不存在老数据，直接写了一条新的，从而产生重复。

• V4.0.0

V4.0.9

• 升级至最新版本。升级至最新版本后，增加了对于错误文件的检测逻辑，如果扫描到写错的文件，报错如下clustered_index size [x] incorrect。此时需要你对报错的表执行 Full Compaction操作修复文件。更多说明请参见分区表常见问题。

P1

升级到V4.0版本后，出现Worker OOM 报错，报错信息类似。报错1：ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

报错2：ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

为了能够在内存中缓存更多的数据，V4.0 版本优化了内存结构，新的内存结构对于数据大小计算不准，导致过小的预估了需要放进内存的数据，最终导致了内存不够引起了worker OOM。

• V4.0.0

V4.0.7

• 关闭 Result Cache，临时绕过该问题。

ALTER DATABASE <database_name> set hg_experimental_enable_result_cache=off;

• 升级至最新版本。

等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P1

在Flink实时写入场景中，drop当前用户，后在创建同名的有权限的用户，即使新建连接，仍然报错没有权限。

FixedFE组件用户权限缓存更新策略问题。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.21

• V4.0.9

• 升级至最新版本。

P1

Dynamic Table 使用 Stream 模式增量刷新数据时，对 base 表做insert/update/delete，立刻truncate或insert overwrite，再次刷新时，刷新数据不正确。

Dynamic Table 使用 Stream 模式增量刷新数据时，对 base 表做insert/update/delete，立刻truncate或insert overwrite，再次刷新时，同一个主键可能消费到重复的delete消息，导致Dynamic Table结果不正确。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升级至最新版本。

P2

通用型实例执行SELECT hg_rebalance_instance()进行rebalance时报 shard group not found的错误。

通用型实例rebalance默认传参错误，导致报错。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升级至最新版本。

P2

扩缩过程中，在 Table Group 的 Leader 计算组和 Follower 计算组目前会很低概率遇到 ShardPermissionDenied的报错，导致秒级的写入失败。

扩缩过程中，在 Table Group 的 Leader 计算组和 Follower 计算组目时预期会捕捉失败，并重试，但是ShardPermissionDenied的报错，没有转为可重试的 kShardHotMigrationInProgress，导致报错到用户端

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升级至最新版本。

P2

访问 MaxCompute 链路切换到 Common Table 链路后，当 Dynamic Table 使用了 MaxCompute 外表时，刷新报错，报错信息如下：

MaxCompute csdk open reader failed: set_reader_filter, parser filter error: (Invalid: File is smaller than indicated metadata size) filter= (ARROW1)

Dynamic Table传递plan的方式和普通olap query不同，传递过程中传递的binary被写坏了，导致filter解析失败。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.36

• V3.2.17

• V4.0.6

• 关闭 Common Table 访问链路，临时绕过该问题。

ALTER DATABASE <database name> SET hg_experimental_external_catalog_routing = 'odps:holo_native,dlf:hqe';

• 升级至最新版本。

P2

使用专家权限模型时，在用户被赋予 Dynamic Table 的 Owner 权限后，使用Dynamic Table的Owner身份对历史表或者分区刷新时，仍报错Permission Denied。

因为刷新的身份时首次刷新缓存下来的，导致修改权限身份后报错。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• 升级至最新版本。

P2

查询DLF的数据时，对timestamp列的进行range filter查询时报错，报错信息如下：

ERROR:  XX000: Dispatch query failed: Internal error: hos_exception: Internal error: status { code: SERVER_INTERNAL_ERROR message: "Call iterator Next() Failed: is_meta_mirror_iter: 1, error: hos_exception: [meta_util.cc:292 CompareSimpleValue] HGERR_code XX000 HGERR_msge internal error: value1 should has long literal HGERR_end" err_data { filename: "snapshot_api.cc" lineno: 1136 funcname: "GetSnapshotDataSetBatch" sqlerrcode: 2600 message: "internal error: Call iterator Next() Failed: is_meta_mirror_iter: 1, error: hos_exception: [meta_util.cc:292 CompareSimpleValue] HGERR_code XX000 HGERR_msge internal error: value1 should has long literal HGERR_end" context: "" } }

literal类型错误处理错误，错误的使用了long进行处理

• V3.2.0

• V4.0.0

• V3.1.17

• V4.0.6

• 关闭 Bigmeta 访问链路，临时绕过该问题。

ALTER DATABASE <database_name> set hg_experimental_enable_big_meta=off;

• 升级至最新版本。

P2

当主键中包含boolean类型的列，且DML插入数据少于10条时，报错，报错信息如下：

ERROR:  XX000: internal error: hos_exception: [literal.cc:181 Init] HGERR_code XX000 HGERR_msge internal error: Unsupported output data type BOOL in type { id: LIST children { id: BOOL nullable: false field_name: "is_ciga" } } long_literal { array { values: 0 values: 0 values: 0 values: 0 values: 0 values: 0 values: 0 } }. HGERR_end

Query Engine会把boolean类型的array转化为uint8 array，hybrid dml在创建row group filter时未考虑这个场景，导致row group filter里literal的类型（bool）和实际的值类型（long）不匹配。

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.7

• 关闭hybrid dml，临时绕过该问题。

ALTER DATABASE <database_name> set hg_experimental_enable_hybrid_dml = off;

• 升级至最新版本。

P2

使用Remote UDF 时，报错如下：

 [Invoke function 'random_between' qualifier 'LATEST' compression 'None' failed: Fail to check http status: 403, {"RequestId":"xxxxx","Code":"SignatureNotMatch","Message":"The request signature we calculated does not match the signature you provided. Check your access key and signing method."} with request: Request {
  url: /2023-03-30/functions/random_between/invocations,
  method: POST,
  params: {qualifier: LATEST},
  headers: {Authorization: xxxxx}

调用时多线程处理存在问题，导致最终报错。

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.8

• 升级至最新版本。

P1

Dynamic Table 使用 Stream 模式增量刷新数据时，若 base 表 compaction 后立刻 refresh，可能会导致增量数据乱序。

因为同一个key消费到的增量是乱序的，会导致最终的sink表结果错误。

• V3.1.0

• V3.2.0

• V3.1.23

• V3.2.6

• 升级至最新版本。

P1

针对Rebuild功能：

• 未开启Binlog模式：将物理分区表Rebuild成逻辑分区表时，最终的逻辑分区表会错误地开启Binlog。

• 开启Binlog模式：物理分区表Rebuild成逻辑分区表时，最终的逻辑分区表未开启Binlog。

rebuild partition to logical partition操作时，对Binlog的处理逻辑存在错误。

• V3.1.1

• V3.2.1

• V4.0.1

暂未修复

P2

使用create table as读的是DLF外表，报错如下：

check permission for dlf table failed: failed to check permission: DLF error,

create table as在读取DLF V2.0的表时，权限读取错误。

• V3.0.1-V3.0.49

• V3.1.1-V3.1.34

• V3.2.1-V3.2.16

• V4.0.1-V4.0.4

• V3.0.50

• V3.1.35

• V3.2.17

• V4.0.6

• 升级至最新版本，并改用Rebuild功能。

P2

源表使用了数据脱敏，当使用create table as语句时，报错the insert table has not set security label。示例 SQL 如下：

create table tb1(id int, data text);
insert into tb1 select i, i::text from generate_series(1, 10) i;
security label for hg_anon on column tb1.data is 'default_value';

set hg_anon_enable = t;
create table bk as select * from tb1;

数据脱敏的设置没有传递到create table as过程中，导致报错。

• V3.1.1-V3.1.32

• V3.2.1-V3.2.12

• V4.0.1-V4.0.2

• V3.1.33

• V3.2.13

• V4.0.3

• 升级至最新版本，并改用Rebuild功能。

P0

用户使用array高阶函数时，如果返回结果数组里面的元素都是相同的，则有可能去重为只有一个元素的数组。示例SQL：

create table tbl1(col1 text[]);
insert into tbl1 values(array['1', '1']);
select hg_array_map(lambda[x => '1' || '1'], col1) from tbl1; 
# 返回结果是{11}, 预期是{11, 11}

create table tbl2(col1 jsonb);
insert into tbl2 values('{"a": "a", "b": "b", "c": null}');
select hg_array_map(lambda[x => col1 ->> x], array['c', 'd']) from tbl2; 
# 返回结果是{NULL}, 预期是{NULL, NULL}

select hg_array_map(lambda[x => case when col1 ->> x is null then '' else col1 ->> x end], array['c', 'd']) from tbl2;
# 返回结果是{''}, 预期是{'', ''}

select hg_array_map(lambda[x => case when col1 ->> x is null then '1' else col1 ->> x end], array['c', 'd']) from tbl2;
# 返回结果是{1}, 预期是{1, 1}

数组计算框架对所有元素相同的数组处理存在缺陷。

• V3.2.1-V3.2.16

• V4.0.1-V4.0.5

• V3.2.17

• V4.0.6

• 升级至最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

使用 HoloWeb 的 Table Resharding 功能时，若任务异常并点击“取消任务”，发现系统未正确清理临时表。
此时手动执行 DROP TABLE 删除该临时表，会导致 Frontend（FE）卡住，无法响应。

HoloWeb内部集成的清理函数存在缺陷

出现版本：

• V2.0.24

修复版本：

• V2.2.28

升级至最新版本。

P2

HG_MOVE_TABLE_TO_TABLE_GROUP（即Resharding）的目标表，如果表名带有特殊字符，或表名本身为关键字，Resharding 会失败（不报错，但是操作后Table Group没有变化）。

HG_MOVE_TABLE_TO_TABLE_GROUP在需要转义的场合处理存在问题

出现版本：所有版本

修复版本：需要使用V3.1版本Rebuild功能作为替代。

升级至最新版本，并改用Rebuild功能。

P2

Hologres Serverless Computing计算资源后付费账单中，“实例ID”字段错误展示为<instance_id>_<uid>_<region_id>，预期应展示为<instance_id>

底层配置存在问题。

出现版本：所有版本。时间范围为2025-09-09 16:00:00至2025-10-14 16:00:00。

修复版本：所有版本。时间范围为2025-10-14 16:00:00后的账单。

单独处理错误时间段内的账单。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

在系统执行Shard Rebalance（如扩缩容、重启）过程中，若多条请求同时完成，可能导致后台进程异常，进而引发实例读写失败。

后台处理同时执行完成的多条请求时存在缺陷。

出现版本：V3.0.9版本。

修复版本：V3.0.14及以上版本。

升级至最新版本。

P0

Hologres外部表数据导入至内部表时，自适应调整导入速度的功能在同时满足以下条件时会造成数据丢失：

• 使用 INSERT INTO ... SELECT ... 方式导入。

• 系统资源紧张导致导入作业自动调整导入速度。此时，如果外部读取走到SQE链路，可能会导致少量数据片段遗漏，从而造成部分数据丢失。

外部表数据导入至内部表的自适应调整导入速度功能，遇到外部表数据读取回退到SQE链路时，会导致部分数据丢失。

出现版本：

• V3.0.1~V3.0.46版本。

• V3.1.1~V3.1.27版本。

• V3.2.1~V3.2.9版本。

修复版本：

• V3.0.47及以上版本。

• V3.1.28及以上版本。

• V3.2.10及以上版本。

实例级别执行GUC关闭自适应导入功能。

ALTER ROLE ALL SET hg_experimental_enable_adaptive_adjust_bulkload_dop = off;

P1

设置数据脱敏后，对表执行update，查出来的结果没有脱敏。示例sql：

create table tb1(id int, data text);
create table tb2(id int, data text);
insert into tb1 select i, i::text from generate_series(1, 10) i;
insert into tb2 select i, null from generate_series(1, 10) i;
security label for hg_anon on column tb1.data is 'default_value';

set hg_anon_enable = t;
update tb2 set data = tb1.data from tb1 where tb1.id = tb2.id;
SELECT * FROM tb2 LIMIT 2;
id	| data
----|----
1	  | 1
2	  | 2

设置脱敏后，update对脱敏字段处理错误，导致结果未脱敏。

出现版本：

• V3.1.0-V3.1.31

修复版本：

• V3.1.32

升级至最新版本。

P1

实例重启后导致dynamic table不再自动刷新。

后端调度系统异常导致。

出现版本：

• V3.0.0-V3.0.45

• V3.1.0-V3.1.24

• V3.2.0-V3.2.7

修复版本：

• V3.0.46

• V3.1.25

• V3.2.7

• V4.0.0

升级至最新版本。

P1

逻辑分区Dynamic Table，开启自动刷新后，活跃分区是增量刷新模式，当分区结束活跃时间时，仍然为增量刷新没有自动转为全量刷新，且存储不断增加。

系统在处理dynamic table活跃分区时，分区状态处理错误。

出现版本：

• V3.1.0-V3.1.23

• V3.2.0-V3.2.6

修复版本：

• V3.1.24

• V3.2.7

升级至最新版本。

P2

dynamic table设置clustering key，且是nullable属性，在执行alter dynamic table时报错clustering_key should not be nullable。

alter dynamic table时未能正常推导clusteringkey的属性，导致报错。

出现版本：

• V3.1.0-V3.1.31

• V3.2.0-V3.2.11

修复版本：

• V3.1.32

• V3.2.12

升级至最新版本。

P2

列存表不设置clustering key，使用insert on conflict do update离线导入后，再实时写入，会有概率出现重复pk。

离线写入时处理主键的数据有误，导致实时写入没有检测到有重复数据，导致最后概率性出现主键重复。

出现版本：

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

修复版本：

• V3.1.30

• V3.2.10

• V4.0.2

升级至最新版本。

P2

insert on conflict有主键重复时设置了hg_experimental_affect_row_multiple_times_keep_last参数也有主键重复报错duplicate key value violates unique constraint。

数据重复时，keep last的guc设置没有生效导致仍然主键重复报错。

出现版本：

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

修复版本：

• V3.1.30

• V3.2.10

• V4.0.2

升级至最新版本。

P2

升级到V3.1版本后查询含脱敏字段的视图报错relation "xxx" does not exist。

V3.1版本的数据脱敏在处理视图时，对视图中的表名处理错误，导致报错表不存在。

出现版本：

• V3.1.0-V3.1.22

• V3.2.0-V3.2.5

修复版本：

• V3.1.23

• V3.2.6

升级至最新版本。

P2

使用hg_insert_overwrite + external database 读取相关外表时，有概率sql卡住。

hg_insert_overwrite处理external database相关表时访问超时，导致卡住。

出现版本：

• V3.1.0-V3.1.21

• V3.2.0-V3.2.4

修复版本：

• V3.1.22

• V3.2.5

升级至最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

当Query请求出现以下任一情况时，可能在Query结束时触发Worker卡住问题，进而导致后续对相关表的DDL操作以及有LIMIT的Query请求被阻塞：

• Query请求发生内存溢出（OOM）。

• Query请求被手动取消。

• Query请求被手动Cancel或因异常结束。

查询引擎在Query结束时的资源清理过程存在缺陷。

出现版本：

• V3.1.18版本。

• V3.2.3版本。

修复版本：

• V3.1.21及以上版本。

• V3.2.5及以上版本。

• 升级至最新版本

• 发生卡住时重启实例或计算组。

• 执行如下命令关闭新版查询引擎。

  ALTER ROLE ALL SET hg_experimental_enable_qe_v2=off;

P1

使用Holo Client V2.6.0版本，通过阿里云AccessKey（阿里云账号、RAM用户、RAM角色）连接Hologres实例时，在每天的某个时间段内会连接失败。连接失败的时间段与使用Holo Client的客户端时区有关，如东八区为00:00:00+08至08:00:00+08无法连接、西五区为19:00:00-05至00:00:00-05无法连接。

Holo Client V2.6.0版本对时区处理存在问题。

Holo Client V2.6.0版本（与Hologres实例无关）。

将Holo Client升级至V2.6.1及以上版本。

P0

在Hologres V3.1版本中，若实例创建了Dynamic Table并以Stream方式消费基表数据，当Dynamic Table处于只读（ReadOnly）状态时，可能导致实例不断重启。

该场景会导致数据Flush失败，从而触发实例不断重启。

出现版本：

• V3.1.1~V3.1.20版本。

• V3.2.1~V3.2.2版本。

修复版本：

• V3.1.21及以上版本。

• V3.2.3及以上版本。

升级至最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用Serverless Computing导入数据执行失败时，中间文件有概率未删除，导致实例存储量增加。

中间文件清理逻辑有概率失效。

出现版本：V3.1.1版本。

修复版本：V3.1.20及以上版本。

• 重启实例，清理中间文件。

• 升级至最新版本。

P2

使用DLF查询Iceberg的外部表数据时，结果为空，未返回任何数据。

查Iceberg时文件解析错误，导致查询为空。

出现版本：V3.1.1~V3.1.16版本。

修复版本：V3.1.17及以上版本。

升级至最新版本。

P2

使用生成列建表，查询错误ERROR: ORCA failed to produce a plan : Query Translation: No variable entry found due to incorrect normalization of query。示例SQL如下。

CREATE TABLE lpt1 (
  a TEXT,
  b INT,
  ts TIMESTAMP NOT NULL,
  d TIMESTAMP GENERATED ALWAYS AS (date_trunc('day', ts)) STORED NOT NULL
)
LOGICAL PARTITION BY LIST(d);

CREATE VIEW v1 AS SELECT * FROM lpt1;

SELECT * FROM v1 WHERE ts >= '2025-03-12 01:00:00';

表中有生成列，发起查询时，优化器翻译生成列错误，导致查询报错。

出现版本：V3.1.1~V3.1.16版本。

修复版本：V3.1.17及以上版本。

升级至最新版本。

P1

创建Dynamic Table时，Query中有BOOLEAN类型，Refresh报错： ERROR: Internal error: HGERR_code XX000 HGERR_msge can not get pg type string %s: id: UINT8。

Dynamic Table对于BOOLEAN类型的字段推导错误，导致Refresh错误。

出现版本：V3.1.1~V3.1.15版本。

修复版本：V3.1.16及以上版本。

升级至最新版本。

P2

Hologres升级到V3.1版本后，hg_dynamic_table_state_size函数查询结果为空。

hg_dynamic_table_state_size未适配V3.1版本。

出现版本：

• V3.1.1~V3.1.15版本。

• V3.2.0~V3.2.1版本。

修复版本：

• V3.1.16及以上版本。

• V3.2.2及以上版本。

升级至最新版本。

P2

Hologres V3.1版本创建Dynamic Table为增量刷新后，直接删除Dynamic Table，状态表仍然保留。

直接删除增量刷新的Dynamic Table时，状态表没有被正确清理，导致残留。

出现版本：V3.1.1~V3.1.12版本。

修复版本：V3.1.13版本。

升级至最新版本。

P2

跨Schema使用rb_or_cardinality_agg等RoaringBitmap64位函数时，报错：Unsupported agg function:public.rb_or_cardinality_agg。

RoaringBitmap64位相关函数的Schema推导错误，导致跨Schema查询报错。

出现版本：

• V3.1.1~V3.1.11版本。

• V3.2.0版本。

修复版本：

• V3.1.12及以上版本。

• V3.2.1及以上版本。

升级至最新版本。

P2

创建Dynamic Table为逻辑分区表时，Base表指定了字段为NOT NULL，创建时报错：failed:the index xx "xxx" should not by nullable。

CREATE TABLE t1 (
    day DATE,
    key INT NOT NULL,
    val TEXT
);

INSERT INTO t1 VALUES ('20201010', 1, '2'), ('20201111', 2, '4'), ('20201212', 3, 'test');

CREATE DYNAMIC TABLE dt1 
logical PARTITION BY LIST (day) 
WITH (
    clustering_key = 'day', 
    segment_key = 'day', 
    auto_refresh_mode = 'incremental', 
    freshness = '1 hour') AS
SELECT
    day, MAX(key), val
    FROM t1
    GROUP BY day, val;
failed:the index xx "xxx" should not by nullable

Dynamic Table得NOT NULL属性推导错误。

出现版本：

• V3.1.1~V3.1.11版本。

• V3.2.0版本。

修复版本：

• V3.1.12及以上版本。

• V3.2.1及以上版本。

升级至最新版本。

P2

单表物化视图存在SUM(DECIMAL)时，实例会出现短暂重启现象。

单表物化视图计算SUM(DECIMAL)时，由于内存未对齐，导致实例发生了核心转储（coredump）

出现版本：

• V3.1.1~V3.1.17版本。

• V3.0.41~V3.0.43版本。

• V3.2.0~V3.2.1版本。

修复版本：

• V3.1.17及以上版本。

• V3.0.44及以上版本。

• V3.2.2及以上版本。

升级至最新版本。

P1

Hologres实例升级至V3.0.41版本后，使用CommonTable链路查MaxCompute外部表时，内存缓慢上涨。

CommonTable链路查MaxCompute外表时，有内存泄露，导致内存上涨。

出现版本：

• V3.1.1~V3.1.17版本。

• V3.0.41~V3.0.43版本。

• V3.2.0~V3.2.1版本。

修复版本：

• V3.1.17及以上版本。

• V3.0.44及以上版本。

• V3.2.2及以上版本。

升级至最新版本。

P0

在特定并发场景下，对同一张表使用Serverless Computing执行DML操作时，同时执行TRUNCATE/DROP TABLE操作，可能因引擎内部状态同步问题，导致该表所在Shard出现读写异常。

由于引擎并发处理存在问题，引起Shard内部状态异常，受影响的Shard将暂时无法提供读写服务，可能影响业务中部分表的正常访问。

出现版本：

• V2.1.45及以下版本。

• V2.2.45及以下版本。

修复版本：

• V2.1.46版本。

• V2.2.46版本。

• V3.0.27及以上版本。

• V3.1.1及以上版本

• 临时方式：

  • 错峰执行DML和TRUNCATE/DROP TABLE操作。

  • 不使用Serverless Computing执行 DML。

• 推荐方式：

  升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

计算组实例扩容时，计算节点偶发性重启。

系统缺陷，如果表同时存在DML任务、Compaction任务，并执行计算组扩容时，有概率触发。

出现版本：V3.0.1版本。

修复版本：V3.0.28及以上版本。

升级到最新版本。

P1

JSONB列式存储优化和GIN索引一起使用时，实例会异常重启。

JSONB列式存储优化和GIN索引存在不兼容情况。

出现版本：V3.1.1版本。

修复版本：

• V3.0.42及以上版本。

• V3.1.10及以上版本。

• 删除表的GIN索引。

• 升级到最新版本。

P2

Dynamic Table的基表都是View时，执行Refresh会导致实例重启。

当基表是View时，会导致Dynamic Table在Refresh时处理错误，导致实例coredump。

出现版本：V3.1.8版本。

修复版本：V3.1.9及以上版本。

升级到最新版本。

P2

Dynamic Table增量刷新模式下，Query中有ARRAY_AGG函数，当数据全被Agg Filter过滤后，返回结果是空（期望是null）。

无。

出现版本：

• V3.0.40版本。

• V3.1.7版本。

修复版本

• V3.0.41及以上版本

• V3.1.7及以上版本

升级到最新版本。

P1

属性关联漏斗函数（finder_funnel）指定时区时，结果计算错误。指定时区的示例SQL如下：

SELECT
    id,
    finder_funnel (86400000, 57600, 86400, 2, 3, 0, 'Asia/Shanghai', TRUE, eventtime * 1000, eventtime * 1000, event = 1000, event = 1001, event = 1002)
FROM
    a
GROUP BY
    id
ORDER BY
    id;

finder_funnel函数默认是UTC时区，当在SQL中指定时区时，将时区错误的丢弃，导致结果错误。

出现版本：V3.0.40版本。

修复版本：V3.0.41及以上版本。

升级到最新版本。

P2

计算组实例，使用PG_RELATION_SIZE、PG_DATABASE_SIZE、HOLOGRES.HG_RELATION_SIZE查出来的存储不正确。

计算组实例下，使用PG_RELATION_SIZE查询出来的存储会多算，导致结果不正确。

出现版本：V3.0.39版本。

修复版本：V3.0.40及以上版本。

升级到最新版本。

P2

Dynamic Table增量刷新模式下单次刷新时，如果基表中有多行重复的数据，刷新报错ERROR: internal error: Filter has 1 rows but length of columns。

当单次刷新有多行重复数据时，增量刷新处理错误导致刷新报错。

出现版本：V3.0.39版本。

修复版本：V3.0.40及以上版本。

升级到最新版本。

P2

Dynamic Table增量刷新有多表JOIN时，表中有ARRAY字段的Refresh报错XX000: internal error: Not Implements。

有ARRAY字段时，多表JOIN的增量刷新无法正确处理。

出现版本：

• V3.0.38版本。

• V3.1.2版本。

修复版本

• V3.0.39及以上版本

• V3.1.3及以上版本

升级到最新版本。

P1

通过事务向逻辑分区写入数据时，如果分区列数据基数过大导致分区数量超过限制（5200个），则事务Commit时，会发生实例重启。

事务Commit时检查到逻辑分区表的分区数超出限制，进程异常自行终止，导致实例Coredump。

出现版本：V3.1.1版本。

修复版本：V3.1.9及以上版本。

优化导入任务的数据质量，清洗分区键的脏数据，避免分区数量过多。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

读取MaxCompute外表时报错ERROR: XX000: internal error: max compuate csdk get next error: storage/formats/orcfile/orc_reader.cpp(362): RetryableStorageException: ODPS-0010000:BadAllocError:allocated pointer 1b658028 not aligned with 64。

在读取MaxCompute外表时接口转换错误，导致读取外表失败。

出现版本：V3.0.1~V3.0.35版本。

修复版本：V3.0.36及以上版本。

升级到最新版本。

P2

hg_create_table_like复制表coment时发生错误。

hg_create_table_like在复制表comment时识别错误，将表comment复制成了列comment。

出现版本：V3.0.1~V3.0.33版本。

修复版本：V3.0.34及以上版本。

升级到最新版本。

P2

查询数据湖外表时报错ERROR: failed to get foreign table split from hive:Failed to generate splits: IllegalStateException: Weights must be non-negative。

读取外表时，数据格式转换错误，导致报错。

出现版本：V3.0.1~V3.0.30版本。

修复版本：V3.0.31及以上版本。

升级到最新版本。

P1

使用ARRAY_AGG函数后，概率性出现内存持续上涨的情况。

ARRAY_AGG函数存在内存泄露问题，导致内存使用量持续增加。

出现版本：V3.0.1~V3.0.29版本。

修复版本：V3.0.30及以上版本。

升级到最新版本。

P2

CTE查询语句中存在Nested Loop Join时，报错Cannot open a fragment with explicit_seek set to false。

优化器推导JOIN ORDER错误，导致查询报错。

出现版本：V3.0.1~V3.0.27版本。

修复版本：V3.0.28及以上版本。

升级到最新版本。

P2

使用GENERATE_SERIES函数处理DECIMAL类型的字段时，报错generate series first and second arguments should has same type。

优化器对DECIMAL类型字段的精度推导错误，导致报错。

出现版本：V3.0.1~V3.0.25版本。

修复版本：V3.0.26及以上版本。

升级到最新版本。

P2

查看hg_stat_activity的query_id字段，当engine_type={PG}时，query_id的内容不准确。

当engine_type={PG}时，hg_stat_activity汇报query_id错乱，导致query_id不准确。

出现版本：V3.0.1~V3.0.25版本。

修复版本：V3.0.26及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用窗口函数，例如ROW_NUMBER() OVER，处理字段lc_state_split_idx时，报错ORCA failed to produce a plan。

窗口函数处理lc_state_split_idx字段时，将其误识别成了关键字，导致错误的截断，从而无法生成执行计划，最终引发SQL报错。

出现版本：V3.0.24及以下版本。

修复版本：V3.0.25及以上版本。

升级到最新版本。

P1

在Dynamic Table中手动指定Distribution Key时，不生效。

引擎推导错误，导致手动设置的Distribution Key未生效。

出现版本：V3.0.24及以下版本。

修复版本：V3.0.25及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

用BI或开发工具连接Hologres时，没有权限的用户也能看到Database、Schema和Table的元数据信息。

权限控制不严格。

出现版本：V3.0.23及以下版本。

修复版本：V3.0.24及以上版本。

升级到最新版本。

P2

MaxCompute外部表JOIN Hologres_fdw外部表时查询报错error: Build desc failed: Fetch table group shards failed on meta proxy。

Hologres_fdw外部表在JOIN MaxCompute外部表时，如果内部表发生Shard Pruning，会产生逻辑错误，导致查询报错。

出现版本：V3.0.22及以下版本。

修复版本：V3.0.23及以上版本。

升级到最新版本。

P2

Hologres实例升级到V2.2版本后，使用GENERATE_SERIES集合返回函数处理DECIMAL类型字段时报错error: generate series first and second arguments should has same type。

GENERATE_SERIES函数处理DECIMAL字段时，优化器对DECIMAL类型的字段精度推导错误，导致查询报错。

出现版本：V2.2.22及以下版本。

修复版本：V2.2.23及以上版本。

升级到最新版本。

P2

为某个账号设置脱敏规则为all:unmasked，但是未脱敏的情况并未生效，查出来的数据仍然是脱敏。

设置脱敏后，没有正确判断账号的脱敏规则导致查询不符合预期。

出现版本：

• V3.0.1及以下版本。

• V2.2.21及以下版本。

修复版本：

• V3.0.2及以上版本。

• V2.2.22及以上版本。

升级到最新版本。

P2

使用JDBC模式消费Hologres Binlog时，作业抛出Binlog Convert Failed、Java heap space等异常，或部分Shard的数据读取在某个时刻停止，无法继续消费。

在消费Binlog的过程中，如果Flink下游算子反压或其他异常，导致源表数据消费不及时，后端会抛出超时异常。Gateway转发异常到客户过程中存在问题，导致读取数据卡住或数据解析失败报错。

• 出现版本：V2.2.21及以下版本。

• 修复版本：V2.2.22及以上版本。

升级到最新版本，并重启Flink任务。

P2

JSONB列在开启列式存储优化功能后，如果设置了Bitmap索引，将会导致数据写入后Flush和Compaction失败，实例存储量上涨、内存水位上升。

JSONB列式存储优化功能对BINARY类型开启Bitmap索引的处理存在缺陷。

出现版本：

• V3.0.1~V3.0.9版本。

• V2.2.31及以下版本。

修复版本：

• V3.0.10及以上版本。

• V2.2.32及以上版本。

• 升级到最新版本。

• 关闭该表的列式存储优化功能，并重建该表。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

array_agg函数在窗口里的计算结果错误。示例如下：

CREATE TABLE ttt(a text, b int);
INSERT INTO ttt VALUES ('0101', 1), ('0102', 2), ('0103', 3);
SELECT a, array_agg(b) OVER (OEDER BY a DESC) FROM ttt;
--执行结果：
a	array_agg
0103	{3}
0102	{2}
0101	{1}

--正确的结果
a	array_agg
0103	{3}
0102	{3,2}
0101	{3,2,1}

array_agg函数与窗口函数一起计算时，计算逻辑错误导致结果不正确。

出现版本：

• V3.0.1~V3.0.21版本。

• V2.2.38及以下版本。

修复版本：

• V3.0.22及以上版本。

• V2.2.39及以上版本。

升级到最新版本。

P2

创建EXTERNAL TABLE时，含有大写字符的表，查询报错：

CREATE TABLE 'dlf_paimon'.'ods'.'ods_test' ( 'ID' VARCHAR(64) NOT NULL) WITH ( 
  'bucket' = '1', 
  'path' = 'dls://xxx', xxx );
  SELECT * FROM 'dlf_paimon'.'ods'.'ods_test' ；
  ERROR: internal : scan column 'ID' cannot be found in Paimon table

EXTERNAL TABLE在读取包含大写字符的表时，大小写转义错误，导致查询报错。

• 出现版本：V3.0.18及以下版本。

• 修复版本：V3.0.19及以上版本。

升级到最新版本。

P2

未配置OSS Endpoint时，查询DLF中的表报错：

SELECT * FROM openlake_demo_dlf.github_events.ods_github_events_raw;

--报错信息
ERROR: internal error: external dataset reader missing required oss_endpoint option.

未配置OSS Endpoint时，无法正确路由到对应的OSS表，导致查询报错。

• 出现版本：V3.0.17及以下版本。

• 修复版本：V3.0.18及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

Dynamic Table在全量和增量刷新时，若包含DECIMAL类型字段，将报错column type doesn't match, decimal(28, 10) v.s. decimal(38, 10)。

Dynamic Table在全量和增量刷新时，DECIMAL类型字段的精度推导错误，从而导致Refresh报错。

出现版本：V3.0.16及以下版本。

修复版本：V3.0.17及以上版本。

• 手动指定Query中DECIMAL类型字段的精度。

• 升级到最新版本。

P2

UNION ALL两边Query Schema不一致时报错schema's field number from producers are not equal [1 vs 0]。

UNION ALL推导Schema不正确，从而导致报错。

出现版本：V3.0.16及以下版本。

修复版本：V3.0.17及以上版本。

升级到最新版本。

P2

Dynamic Table增量刷新对SMALLINT类型字段进行聚合时，报错不支持。

Dynamic Table增量刷新对SMALLINT类型支持不够完善。

出现版本：V3.0~V3.0.16版本。

修复版本：V3.0.17及以上版本。

升级至最新版本。

P2

升配计算组实例后，查询报错CreateFile ignore since it's not leader。

升配计算组期间，表Meta未及时更新，导致查询时获取的是旧表Meta的数据，从而导致升配后报错。

出现版本：

• V3.0.12~V3.0.15版本。

• V2.0.35及以下版本。

修复版本：

• V3.0.16及以上版本。

• V2.2.36及以上版本。

• 重启升配的计算组。

• 升级到最新版本。

p1

Hologres升级至V3.0.12～V3.0.15版本后，对于开启动态分区的表，如果分区键类型是TEXT，动态分区的调度可能会出现错误，从而导致创建分区表失败。

对于TEXT为分区键时，调度系统处理有问题，会导致内部转换失败，从而建表失败。

出现版本：V3.0.12~V3.0.15版本。

修复版本：V3.0.16及以上版本。

升级到最新版本。

p1

Hologres版本升级至V3.0~V3.0.13版本后，查询MaxCompute外表性能变慢。

自Hologres V3.0版本，加强了获取MaxCompute Table Meta权限检查，这导致FE节点发生多次反复调用，从而降低了查询MaxCompute外部表的性能。

出现版本：V3.0~V3.0.13版本。

修复版本：V3.0.14及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

Dynamic Table全量刷新模式下开启Binlog后，Refresh报错ERROR: internal error: refresh table failed: internal error: new_values is missing col。

Dynamic Table全量刷新模式下开启Binlog后，隐藏列推导不一致，导致Refresh报错。

出现版本：V3.0.11及以下版本。

修复版本：V3.0.12及以上版本。

升级到最新版本。

P2

SLPM权限模型下，删除Orafce Extension再重新创建会报错“role slpm xxx already exists“。

SLPM权限模型下，删除Orafce Extension时用户组的权限未清理干净，导致在重新创建时用户组仍然存在，从而无法成功创建Orafce Extension。

出现版本：V3.0.9及以下版本。

修复版本：V3.0.10及以上版本。

• SLPM改成专家权限模型后再重新创建Orafce Extension。

• 升级到最新版本。

P2

Dynamic Table中有Decimal字段，Refresh时报错invalid definition of a numeric type。

Decimal字段的精度推导不正确，导致Dynamic Table在Refresh时精度不一致而报错。

出现版本：V3.0.9及以下版本。

修复版本：V3.0.10及以上版本。

• 创建Dynamic Table时手动指定Decimal字段的精度。

• 升级到最新版本。

P2

元仓大于10 s的Query偶发出现Plan列没有EXPLAIN ANALYZE结果。

大于10 s的Query在汇报偶发延迟，导致Plan列没有采集到结果。

出现版本：

• V3.0.8及以下版本。

• V2.2.33及以下版本。

修复版本：

• V3.0.9及以上版本。

• V2.2.34及以下版本。

升级到最新版本。

P2

Analyze带BIS类型的表报错Not supported type: bsi0.] in cache failed。

Analyze对BIS类型的字段支持不完善，导致出现报错。

出现版本：

• V3.0.8及以下版本。

• V2.2.31及以下版本。

修复版本：

• V3.0.10及以上版本。

• V2.2.32及以上版本。

升级到最新版本。

P2

使用hg_insert_overwrite后，产生的临时表未自动清理。

hg_insert_overwrite过程中因清理机制未启动，导致临时表未清理。

出现版本：V2.2.30及以下版本。

修复版本：V2.2.31及以上版本。

升级到最新版本。

P2

实例频繁执行DDL操作，若FE节点的版本刚好不一致时执行了TRUNCATE操作，此时对TRUNCATE执行CANCEL时，无法成功CANCEL，可能会导致数据结果不一致。

当FE节点的版本不一致时，会出现节点Relay卡住，导致后续DDL失败，如果期间执行DROP、TRUNCATE，执行CANCEL不会成功。

出现版本：V2.2.26及以下版本。

修复版本：V2.2.27及以上版本。

升级到最新版本。

P2

执行SQL语句过长超出了限制报错：ERROR: Current query length xxx exceeds the limit 10000000。

Hologres增加了SQL长度限制，默认值10000000。

出现版本：

• V2.2.22及以上版本。

• V3.0.1及以上版本。

通过设置如下参数取消SQL长度限制。

ALTER DATABASE db_name SET hg_experimental_query_length_limit = 0;

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

数据库首次开启DML事务后，如果在SQL中对同一表执行并发DDL操作，可能会导致Query卡住等现象。

在数据库首次使用DML事务时，将首先获取表锁。如果该表存在并发的DDL操作，系统将进入尝试建表的循环，概率性出现死锁，导致Query卡住等。

出现版本：V2.2.24及以下版本。

修复版本：V2.2.25及以上版本。

升级到最新版本。

P2

对于包含roaringbitmap类型字段的Hologres表，当通过CREATE FOREIGN TABLE命令创建Hologres跨库查询外表，且外表中不包含roaringbitmap类型字段时，可成功创建外表，但在使用SELECT * FROM方式查询包含roaringbitmap类型的字段时，报错cache lookup failed for type 22243。

跨库查询的外表不支持roaringbitmap类型，在创建外表时需要校验。

出现版本：V2.2.24及以下版本。

修复版本：V2.2.25及以上版本。

升级到最新版本。

P2

使用JDBC prepareStatement方法时，反复执行CREATE EXTENSION命令后报错unrecognized extension: "PostgreSQL JDBC Driver"，而使用其他工具则未发现此问题。示例代码如下：

Connection conn = DBInitializer.BuildSlaveDsOnHolo().getConnection();
List sqls = Arrays.asList(
    "SET application_name TO 'PostgreSQL JDBC Driver'",
    "CREATE EXTENSION IF NOT EXISTS hologres_fdw"
    );

使用JDBC prepareStatement方法循环执行CREATE EXTENSION命令后，导致Cache被破坏，从而出现报错。

出现版本：

• V2.2.23及以下版本。

• V3.0.3及以下版本。

修复版本：

• V2.2.24及以上版本。

• V3.0.4及以上版本。

• 一个数据库只需要执行一次CREATE EXTENSION，无需反复执行。

• 升级到最新版本。

P2

元仓Query Log中的result_rows和affected_rows值与实际值不符。

元仓汇报result_rows和affected_rows时发生错误，导致汇报的值与实际值不符。

出现版本：V2.2.22及以下版本。

修复版本：V2.2.23及以上版本。

升级到最新版本。

P2

计算组实例中，重启主计算组时，可能会导致从计算组点查（基于主键的查询）变慢。

重启主计算组时，正常运行的计算组对应的Shard会轮询主Shard状态，导致点查卡住，直到所有Shard恢复后才会继续执行。

出现版本：V2.2.21及以下版本。

修复版本：V2.2.22及以上版本。

升级到最新版本。

P2

BSI_SUM函数结果数组中，所有元素的总和超出2^31时，结果出错。

函数数据溢出情况误处理。

出现版本：V2.1.1及以上版本。

修复版本：等待修复。

• 修复后升级到最新版本。

• 改写SQL，示例如下：

  SELECT SUM(a[2]) FROM (SELECT BSI_ITERATE(BSI_BUILD('{20240901,1}','{3101397531,100}')) a) b;

P2

连接Hologres实例偶发创建连接超时或卡住，导致无法新建连接。

连接实例偶发节点内进程卡住，导致此节点无法创建新连接。

出现版本：低于V2.2.23，V2.1.43，V2.0.46，V1.3.71的版本。

修复版本：V3.0.4，V2.2.23，V2.1.43，V2.0.46，V1.3.71及以上版本。

• 短期方案：重启实例可暂时解决。

• 长期方案：升级至各版本的最新小版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

计算组实例中，若某个计算组A不可用（如正在重启），其他计算组对A加载的Table Group中的表执行点查时，延迟升高。

实时读写链路内部模块存在缺陷，计算组执行点查时会等待Table Group状态，导致延迟升高。

出现版本：V2.1.1至V2.2.21版本。

修复版本：V2.2.22及以上版本。

升级到最新版本。

P1

Fixed Plan实时写入数据量超过100万QPS时，有小概率触发写入失败和实例重启。

实时读写链路内存管理器存在缺陷。

出现版本：

• V2.0.1~V2.0.43版本。

• V2.1.1~V2.1.36版本。

• V2.2.1~V2.2.8版本。

修复版本：

• V2.0.44及以上的V2.0版本。

• V2.1.37及以上的V2.1版本。

• V2.2.9及以上的V2.2版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

使用jdbc或jdbc_fixed模式读取Hologres的Binlog时，如果Flink作业遭遇反压导致后端超时，有概率导致Flink作业卡住或触发Failover。

Gateway收到后端超时的异常信息时，将异常返回给客户端的过程中存在问题，导致读取数据卡住或数据解析失败报错。

出现版本：V1.3及以上版本。

修复版本：V2.2.21及以上版本。

从最新的checkpoint直接重启作业，并升级到最新版本。

P2

在V2.2版本之后，使用了Shard Pruning（执行计划中包含Shard Prune算子）的COUNT DISTINCT操作，通过PQE执行，导致计算性能下降。

CREATE TABLE t1 (a int, b int) WITH (distribution_key = 'b');
INSERT INTO t1 VALUES(1,1),(2,2),(3,3),(4,4);
EXPLAIN SELECT count(DISTINCT a) FROM t1 WHERE b =1;
--返回结果如下
QUERY PLAN
Final Aggregate  (cost=0.00..105.00 rows=1 width=8)
  ->  Partial Aggregate  (cost=0.00..5.00 rows=1 width=8)
        ->  Partial HashAggregate  (cost=0.00..5.00 rows=10 width=4)
              Group Key: a
              ->  Local Gather  (cost=0.00..5.00 rows=32 width=4)
                    ->  Partial HashAggregate  (cost=0.00..5.00 rows=32 width=4)
                          Group Key: a
                          ->  Seq Scan on t1  (cost=0.00..5.01 rows=1000 width=4)
                                Shard Prune: Eagerly
                                Shards selected: 1 out of 21
                                Filter: (b = 1)
                                RowGroupFilter: (b = 1)
Optimizer: HQO version 2.2.0

使用Shard Pruning后，COUNT DISTINCT的执行计划推导错误，导致通过PQE执行，影响查询性能。

出现版本：V2.2.1至V2.2.18版本。

修复版本：V2.2.19及以上版本。

• 升级到最新版本。

• 将COUNTDISTINCT替换为UNIQ。

P2

慢Query日志（query_log表）中query_start字段的日期格式为2024-07-08 22:00:00，而query_date字段日期格式为19700101。

慢Query日志中的query_date字段数据采集错误。

出现版本：V2.2.1至V2.2.18版本。

修复版本：V2.2.19及以上版本。

升级到最新版本。

P2

在写入分区子表时，若COPY列中包含了分区列，并且当分区值为0时，传入其他非0值也能正常写入，这可能导致分区值出现脏数据。

begin;
create table tp(a int, b int) partition by list (a);
create table c0 partition of tp for values in (0);
commit;

COPY c0 FROM stdin WITH (stream_mode ON, format 'csv', null 'null');

# 输入
1,0
null,0
\.

在写入分区子表时，如果copy列中包含了分区列，并且分区值为0，系统缺少对分区值为0的检查，从而导致脏数据成功写入。

出现版本：V2.2.1至V2.2.18版本。

修复版本：V2.2.19及以上版本。

升级到最新版本。

P2

在连接串上显示的设置时区为SET timezone='+8'，且Query中含有PQE日期函数，例如to_char。执行结果将为西八区的日期（应为东八区）。示例：

CREATE TABLE date_test(a timestamptz);
--返回结果：2001-09-28
INSERT INTO date_test VALUES ('2001-09-28 03:00:00+08');
SELECT to_char(a, 'YYYY-MM-DD') FROM date_test;

--错误的结果： 2001-09-27
SET hg_experimental_udf_pushdown_blacklist =timestamptz_to_char;
SET timezone='+8';
SELECT to_char(a, 'YYYY-MM-DD') FROM date_test;

连接串上指定了时区后，PQE在解析日期函数时计算时区错误，导致结果错误。

出现版本：V2.2.1至V2.2.18版本。

修复版本：V2.2.19及以上版本。

升级到最新版本。

P2

使用pad_sub_cost函数时报错Column should be non-nullable but the values contain 609 nulls。

pad_sub_cost函数在计算时Nullable属性推导错误，导致查询报错。

出现版本：V2.2.1至 V2.2.18版本。

修复版本：V2.2.19及以上版本。

升级到最新版本。

P0

使用动态分区管理功能时，如果time_unit设置为MONTH，即按月创建动态分区，则可能会误创建未来分区、误删除当前分区。

自V2.2版本开始，动态分区管理功能支持自定义调度开始时间，对于按月分区时间计算有误。

出现版本：V2.2.1至V2.2.17版本。

修复版本：V2.2.18及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

执行hg_insert_overwrite、CREATE TABLE AS

和COPY命令操作外部表时遇到报错： Fail to access foreign data as user xxx, no token found in request header。

自V2.2版本开始，MaxCompute外部表操作需要通过服务关联角色（SLR）来进行身份验证。由于当前实现存在问题，已创建SLR的用户在执行hg_insert_overwrite、CREATE TABLE AS

和COPY命令操作时会遇到外部表访问失败的情况。

出现版本：

V2.2.1至V2.2.14版本。

修复版本：

V2.2.15及以上版本。

升级到最新版本。

P1

源表存在重复数据，执行UPDATE或UPSERT并基于PK去重，目标表将偶发出现重复数据，且表数据TTL没有过期。

执行UPDATE或UPSERT时，是目标表和源表JOIN，如果两个表的JOIN KEY不一致，目标表会出现Redistribution。这种情况下，如果源表有重复数据，会导致优化器在处理重复数据时逻辑错误，数据未能正常去重，导致最后主键重复。

出现版本：

V2.2.13及以下版本。

修复版本：

V2.2.14及以上版本。

升级到最新版本。

p2

通过Flink将Paimon数据读取并写入Hologres时，Paimon VARCHAR类型数据与Hologres数据格式不一致。

Paimon中VARCHAR类型的数据：中国
写入Hologres后的VARCHAR类型的数据为：？？？（乱码）

Hologres对Paimon VARCHAR类型的数据转换错误，导致出现乱码。

出现版本：

V2.2.12及以下版本。

修复版本：

V2.2.13及以上版本。

升级到最新版本。

p2

IS DISTINCT FROM语法，对NaN数据处理和PostgreSQL不一致。

--PostgreSQL的行为：
CREATE TABLE test_f8 (a float8);
INSERT INTO test_f8 VALUES ('NaN');
SELECT * FROM test_f8 WHERE a IS DISTINCT FROM 'NaN';
-- 返回结果如下
 a
---
(0 rows)
--------------------------------------------------------
Hologres的行为：
CREATE TABLE test_f8 (a float8);
INSERT INTO test_f8 VALUES ('NaN');
SELECT * FROM test_f8 WHERE a IS DISTINCT FROM 'NaN';
-- 返回结果如下
  a  
-----
 NaN

为了能够利用索引，PostgreSQL定义了NaN和其他数字的大小比较规则，将NaN值视为相等，且大于任何非NaN值。而Hologres在实现时遵循了C++标准的比较规则，因此NaN值互不相等，导致结果与PostgreSQL不一致。

出现版本：

V2.1.37及以下版本。

修复版本：

• V2.1.38及以上版本。

• V2.2.10及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用Fixed Plan点查多个相同主键值时（例如select * from table_name where (pk=1) or (pk=1);），会返回多条相同结果。

Fixed Plan没有对相同主键的多组过滤条件进行去重。

出现版本：

V2.2.8及以下版本。

修复版本：

V2.2.9及以上版本。

• 避免一个SQL语句的where过滤条件中存在多组相同主键（pk）值。

• 升级到最新版本。

P1

在Rebalance过程中，执行Schema Change的相关操作后，实例无法正常写入和查询。

在Rebalance过程中，当Shard的Leader和Follower延迟小于10秒时，将进行Follower和Leader的切换。在切换时，若用户执行Schema Change的相关操作，会导致存储引擎SE的状态异常，进而导致实例无法进行正常的写入和查询操作。特别是在Hologres V2.1版本中，当实例存在空Worker节点时，会自动触发Rebalance机制，从而增加了该问题发生的概率。

出现版本：

• V2.1.16至V2.1.23版本。

• V2.0.0至V2.0.41版本。

修复版本：

• V2.1.24及以上版本。

• V2.0.42以上版本。

升级到最新版本。

P2

Hologres实例升级至V2.1.25及以上版本后，对非public下的表执行insert overwrite语句时，产生的临时表未能自动清理。

对insert overwrite语句，在执行时检测疏漏，导致临时表未能正常清理掉。

出现版本：

V2.1.25至V2.1.32版本。

修复版本：

V2.1.33及以上版本。

• 使用HoloWeb表管理功能，一键清理临时表。

• 升级到最新版本。

P2

使用FixedFE（对应Connector中的jdbc_fixed模式）写入数据到Hologres过程中，开启SLPM模型并授予用户对应Schema的开发者（developer）权限，但FixedFE出现报错permission denied for schema XXX。

FixedFE在SLPM模型权限变化时，没有及时刷新缓存，导致用户已有权限，却仍然出现相关报错。

出现版本：

V2.0.31及以下版本

修复版本：

V2.0.32及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用datediff函数按照指定的单位计算两个时间差值时，偶发返回结果与实际结果相差1。

该函数计算存在逻辑缺陷。

出现版本：

V2.0.31版本。

修复版本：

V2.1.27及以上版本。

升级到最新版本。

P2

Hologres实例升级至V2.1.26版本后，监控指标显示实例内存分布使用率中的Query内存缓慢上涨。

升级至V2.1.26版本，当Query出现OOM问题后，内存指标会被重复统计，导致监控中内存相关的指标上涨。

出现版本：

V2.1.26版本。

修复版本：

V2.1.27及以上版本。

升级到最新版本。

P1

Hologres实例升级至V2.1版本，且在实例中进行MaxCompute外部表查询时，出现实例内存缓慢上涨现象，Query性能出现抖动，或者OOM较多。

使用V2.1版本实例查询MaxCompute外部表时，打开的文件未被及时关闭，导致内存缓慢上涨，影响了Query性能或者实例稳定性。

出现版本：

V2.1.1至V2.1.25版本。

修复版本：

V2.1.26及以上版本。

升级到最新版本。

P2

V2.1版本中，主从实例或计算组实例的存储容量变多，表现为监控指标的存储使用总量大于通过pg_relation_size函数计算的存储总量。

V2.1版本的主从实例或计算组实例回收旧文件不及时，导致存储容量增长，监控采集的存储量变多。

出现版本：

V2.1.1至V2.1.25版本。

修复版本：

V2.1.26及以上版本。

升级到最新版本。

P1

Flink通过JDBC模式消费Hologres Binlog时，出现作业启动时消费速率较高，之后持续下降的情况。

Flink通过JDBC模式消费Hologres Binlog时，存在内存泄漏问题。

出现版本：

VVR V6.0.7以下版本。

修复版本：

VVR V6.0.7及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

由于查询资源未释放导致：

• 内存持续上涨。

• 大量锁占用。

• 大量查询因为分配不到资源导致卡住，即使重启实例，也无法明显缓解，在短时间内，仍会卡住。

当查询仅涉及Shard数据，且使用了PQE或SQE执行MaxCompute外部表或数据湖外部表的查询时，查询完成后不会系统主动触发资源回收，只能使用Query Master的垃圾回收机制来回收资源。当Query Master压力较大时，查询操作会因退出延迟而占用大量资源，导致后续的查询无法执行。

出现版本：

V2.1.23至V2.1.24版本。

修复版本：

V2.1.25及以上版本。

升级到最新版本。

P1

对字典编码过的列添加bitmap，导致not null的列查询结果错误，出现null值。

对字典编码过的列添加bitmap，后端构建bitmap时，未对全部数据生效，导致结果有错误。

出现版本：

V2.1.21及以下版本。

修复版本：

V2.1.22及以上版本。

升级到最新版本。

P1

通过Fixed Plan进行数据的实时写入或点查，实例内存使用率逐渐上涨。

Hologres V2.1版本中Fixed Plan执行引擎进行了重构，其为读写表创建的operator没有及时清理，导致内存泄露。

出现版本：

V2.1.1至V2.1.9版本。

修复版本：

V2.1.10及以上版本。

升级到最新版本。

P1

对运行在PQE上的Query执行取消（cancel）操作时，有概率触发对应PQE节点的进程死锁，无法处理新的PQE请求。

PQE IO并发控制功能缺陷，当PQE接收到cancel信号时有概率触发。影响所有PQE进程。

出现版本：

• V2.1.2至V2.1.8版本。

• V2.0.23至V2.0.30版本。

修复版本：

• V2.1.9及以上版本。

• V2.0.31及以上版本。

升级到最新版本。

P2

INTERSECT或EXCEPT函数在Shard Pruning时，出现执行结果与实际结果不一致。例如在Shard Pruning时，执行如下示例SQL，返回结果可能与实际结果不符。

SELECT * FROM (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1) 
a INTERSECT (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1);
  
--返回结果，不正确
user_id   
-------
 2
 
--实际结果，正确
user_id   
-------
 1

当前INTERSECT或EXCEPT函数是通过JOIN实现，在Shard Pruning时，对于INTERSECT或EXCEPT函数的处理导致执行计划不正确，结果出现错误。

出现版本：

V2.1.21及以下版本。

修复版本：

V2.1.22及以上版本。

升级到最新版本。

P2

在PQE进程退出时，存在小概率的卡死现象，持续积累后会导致PQE无法处理新的请求。

PQE进程退出时，启动的RPC退出线程和主线程存在并发问题，导致RPC退出线程无法正常结束，进而导致PQE进程无法顺利退出。

出现版本：

V2.1.0至V2.1.14版本。

修复版本：

V2.1.15及以上版本。

升级到最新版本。

P2

并发执行PQE的Query时，实例出现短暂重启现象。

Hologres V2.0及以下版本中，PQE存在多线程并发问题，导致实例概率性的出现Coredump。

出现版本：

V2.0及以下版本。

修复版本：

V2.1.0及以上版本。

升级到最新版本。

P2

使用Prepared Statement模式执行包含in ($1....)的SQL，并经过分片选择器（shard selector）进行处理时，出现了实例短暂重启现象。

优化器生成Plan错误，导致实例出现Coredump。

出现版本：

V2.0及以下版本。

修复版本：

V2.1.0及以上版本。

升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

TEXT类型先转换为BIT类型，再转换成BIGINT类型报错：Cast FROM STRING to BINARY is not supported.。示例SQL：

CREATE TABLE ttttt (a text);
INSERT INTO ttttt VALUES ('x165a7b4a00001');

SELECT * FROM ttttt;
SELECT a::bit(52)::bigint FROM ttttt; 


--text转bit报错不支持 ：Cast FROM STRING to BINARY is not supported.
--text转bit，再转bigint报错 ：ERROR: syntax error at or near ")"

TEXT类型转BIT类型支持不完善，导致出现报错：Cast FROM STRING to BINARY is not supported.。然后BIT类型再转BIGINT类型会错误识别BIT类型，出现报错：syntax error at or near ")"。

出现版本：

V2.1.20及以下版本。

修复版本：

V2.1.21及以上版本。

升级到最新版本。

P2

行存表指定了PK，Clustering Key设置为空串时，出现元数据不一致导致Query卡住。示例建表SQL：

BEGIN;
DROP TABLE IF EXISTS public.t01;
CREATE TABLE public.t01 (
  agree_time timestamp without time zone,
  seller_id int NOT NULL,
  seller_nick text NOT NULL,
  ref_id bigint NOT NULL,
  scope text NOT NULL,
  status integer NOT NULL,
  PRIMARY KEY (seller_id)
);
CALL set_table_property('public.t01', 'orientation', 'row');
CALL set_table_property('public.t01',  'clustering_key', '');
END;

行存表的Clustering Key为空串时，与PK不一致，FE节点响应请求失败，从而造成元数据不一致，导致Query停滞。

出现版本：

V2.1.20及以下版本。

修复版本：

V2.1.21及以上版本。

• 重新建表，并显式指定Clustering Key（建议行存表Clustering Key和PK一致，才能发挥更好的性能）。

• 升级到最新版本。

P2

Query的过滤条件（where）中包含Clustering Key，且使用Order By对Clustering Key排序，如where a >= xxx limit x order by a，a列是Clustering Key，Query计算结果不正确。示例SQL：

BEGIN;
CREATE TABLE test3(a int NOT NULL);

CALL set_table_property('test3', 'clustering_key', 'a');
CALL set_table_property('test3', 'segment_key', 'a');
CALL set_table_property('test3', 'distribution_key', 'a');
END;
INSERT INTO test3 SELECT i FROM generate_series(0, 100000)i;
INSERT INTO test3 SELECT 500 FROM generate_series(0, 100000)i;

SELECT count(1) FROM (SELECT * FROM test3 WHERE a>=500  AND a <= 500 ORDER BY a ASC LIMIT 20 OFFSET 11440)a;
--出现结果异常，limit 20，但是返回的数据可能是30

当过滤条件中有Clustering Key，且使用Order By对Clustering Key排序，会导致Order By的算法匹配错误，从而出现返回的结果与LIMIT的结果不正确。

出现版本：

V2.1.19及以下版本。

修复版本：

V2.1.20及以上版本。

升级到最新版本。

P1

在Hologres V2.1版本中，实例内存使用率有缓慢上涨，查询MaxCompute外部表时，偶发出现ERPC_ERROR_CONNECTION_CLOSED报错。

实例升级到 V2.1版本后，由于外部表的底层数据文件没被及时关闭，导致内存泄漏，偶发引起实例重启。

出现版本：

V2.1.10至V2.1.18版本。

修复版本：

V2.1.19及以上版本。

升级到最新版本。

P2

DECIMAL类型相乘后精度不符合预期。示例SQL：

CREATE TABLE t (a decimal(30,10), b decimal(30,10));
INSERT INTO t VALUES (1.1111111111, 1.0000000000),(1.1111111112, 1.0000000000),(1.1111111111, 2.0000000000),(1.1111111112, 2.0000000000);
SELECT a*b FROM t;

--Hologres结果，不正确
2.222222222000000000
1.111111111000000000
1.111111111000000000
2.222222222000000000

--PG结果，正确
2.222222222000000000
1.111111111000000000
1.111111111000000000
2.222222224000000000

DECIMAL类型乘法默认小数精度是18位，两个DECIMAL类型相乘后小数位数超过18时，会导致将数据截断再计算，从而出现结果不符合预期。

出现版本：

V2.1.18及以下版本。

修复版本：

V2.1.19及以上版本。

• 将DECIMAL类型转换（CAST）为TEXT类型。

• 升级到最新版本。

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

升级到Hologres V2.1版本后，truncate后再执行INSERT操作会偶发报错：Invalid table id in schema。

Hologres V2.1版本FrontEnd错误增加了过长的replay缓存时间，导致同一个DDL后再执行DML，DDL replay会变慢。

出现版本：

V2.1.1至V2.1.14版本。

修复版本：

V2.1.15及以上版本。

升级到最新版本。

P2

jsonb_to_textarray函数不支持常量折叠导致SQL带有常量计算时会报错：ERROR: internal error: The left deepest leaf node of columnar access ref。示例SQL：

CREATE TABLE t2 (f1 text[]);
INSERT INTO t2 VALUES (ARRAY['1']);
SELECT f1 && jsonb_to_textarray('["1","2"]') FROM t2;

--报错
ERROR:  internal error: The left deepest leaf node of columnar access ref

在SQL中jsonb_to_textarray函数计算有常量时下推错误，从而出现报错。

出现版本：

• V2.1.1至V2.1.14版本。

• V2.0.34及以下版本。

修复版本：

• V2.1.15及以上版本。

• V2.0.35及以上版本。

升级到最新版本。

P2

使用regexp_split_to_array函数偶发报错：ERROR：Illegel udf8 string in xxxx。

regexp_split_to_array函数越界读取到非预期的内存地址，导致查询失败。

出现版本：

V2.1.1至V2.1.12版本。

修复版本：

V2.1.13及以上版本。

升级到最新版本。

P2

使用SELECT * FROM <table_name> LIMIT xxx;可能会偶发性卡住。

对于全表扫描带LIMIT的场景，Hologres会通过惰性加载（lazy loading）的方式加载数据，一次性扫描太多数据导致卡住。

出现版本：

• V2.1.1至V2.1.11版本。

• V2.0.33及以下版本。

修复版本：

• V2.1.12及以上版本。

• V2.0.34及以上版本。

升级到最新版本。

P2

对实例执行重启、升级、升降配等涉及实例重启的操作后，MaxCompute直读Hologres外部表时，偶发任务卡住。

对于Hologres表，后台会定期触发元数据更新，实例重启后，系统会重新刷新一次表的元数据，MaxCompute直读Hologres未能及时获取元数据状态，导致任务卡住。

出现版本：

• V2.1.0至V2.1.2版本。

• V2.0.5及以下版本。

修复版本：

• V2.1.3及以上版本。

• V2.0.26及以上版本。

升级到最新版本。