AI 助理
文档备案控制台
官方文档
首页

关键缺陷通知

更新时间：
复制 MD 格式
产品详情
我的收藏

本文将为您介绍Hologres各版本相关缺陷的修复记录，包括问题描述、影响程度等。您可以通过报错或问题描述，检查您当前的业务中是否产生了相关问题，提前进行问题规避。建议加入实时数仓Hologres交流群联系对应技术支持协助您将产品升级到最新版本，详情请参见如何获取更多的在线支持？。

背景信息

  • 缺陷及修复说明

    • 缺陷内容向下穿透：当前版本存在的缺陷，在之前的版本中均存在。

      例如，V1.3版本中存在某缺陷，在V1.1或V0.10等版本中大多数存在，少数不存在场景有明确标注。

    • 缺陷修复向上包含：当前版本修复后的缺陷，在之后的版本中均已修复。

      例如，V1.1版本中已修复的某缺陷，在V1.1或V1.3等版本中均已修复。

  • 缺陷等级说明

    • P0：建议立即升级，一旦触发会影响线上的使用（如查询正确性、写入成功率等操作）。

    • P1：推荐升级，提前规避相关问题。

    • P2：选择性升级，偶尔发生的问题，具备应该改写方法，或重启即可修复。

2026年缺陷

2026年7月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P1

Hologres 仅部分功能支持 create index 语法（如全文倒排索引），但部分其他场景的 create index if not exists on xx; 可执行，未正确拦截。错误执行后，FE 上元数据出现不一致，此行为会导致不同 FE 上关于该 index 的 meta 不一致。现象表现为：在某些时候能看到该 index，某些时候看不到该 index。在开启了回收站的场景下，此时删除带该 index 的表时（即进入回收站），有可能发生 replay delay，即使此时没有发生，在回收站真正删除该表时也会发生 replay delay。发生 replay delay 后，实例将无法执行 DDL，并同时可能观察到的现象为：有时能看到被删除的表，有时看不到。

用户能错误地成功执行不支持的 create index if not exists on xx;

V4.2.0~V4.2.9

V4.2.10

  • 升级到最新版本。

  • 临时绕过：在执行 drop 有问题的表（即进入回收站）前，关闭回收站可以避免 replay delay 的发生。

  • 当发生了 replay delay 后，必须由值班同学手动修复。

2026年6月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P0

逻辑分区表更新部分主键时，flush数据可能导致实例重启

逻辑分区表在更新主键场景存在缺陷

V3.1.1

V3.2.29、V3.1.43

升级到最新版本。

P0

数据写入过程中报错Partition count [65535] in memtable has exceed the limit [65535]后Worker重启

内存表memtable分区数限制检查存在缺陷，未正确统计本次待写入分区数，导致Worker自杀

V4.0.1

V4.1.21、V4.2.2、V4.0.37

2026年5月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P1

对开启Binlog的表执行Rebuild时，有概率出现接入节点卡住，实例不可用

Rebuild底层在处理开启Binlog的表时存在缺陷

V4.1.1

V4.1.21

  • 升级到最新版本。

  • 关闭GUC set hg_experimental_rebuild_try_to_using_dynamic_table_mode=off后执行Rebuild。

P2

连接实例时在options内设置多项配置会使得连接失败或配置值错误。如连接时设置options为-c statement_timeout=1000 -c search_path=public，则连接失败，报错Connect to FE failed, invalid value for parameter "statement_timeout": "1000-csearch_path=public"

网关模块处理options字段时错误地忽略了空格

  • V2.0.18~V2.0.35

  • V2.1.1~V2.1.15

  • V2.0.36

  • V2.1.16

  • 升级到最新版本。

  • 避免在连接options中设置超过一个配置。

2026年4月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P2

使用数据脱敏 V2版本查询含有脱敏表的VIEW时可能错误地出现permission denied for schema xxx或者permission denied for table xxx报错信息

数据脱敏对于权限拦截错误导致报错

  • V4.0.1~V4.0.27

  • V4.1.1~V4.1.12

  • V4.0.28

  • V4.1.13

升级到最新版本。

P1

创建了全局二级索引（Global Index）的表执行DML时，如果执行计划使用Shard Prune算子，会报错Transaction xxxxxxxxxxxxx has no snapshot of table xxxxx index 1.

全局二级索引暂不支持处理Shard Prune算子

V4.0.1

待修复

  • 针对报错Query，关闭GUC hg_experimental_enable_shard_pruning。

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

2026年3月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

P1

全文倒排索引的短语检索模式时，如果设置slot参数大于255，检索结果可能不正确。

全文倒排索引针对slot大于255时的匹配逻辑存在缺陷。

V4.0.1

V4.1.9

  • 升级至最新版本。

  • 避免设置slop>255。

P2

动态表incremental刷新模式下，Volatile函数下接Agg且Volatile不在最后一列时，刷新失败。报错：

ERROR: Feature not supported: Distribution key must be contained by output columns, residual key list:[3, ]

distribution key list被带到内层查询，但distribution key list对应的是最终output column，与内层列无法对应。

V3.1

  • V4.1.8

  • V4.0.24

  • 绕过方式：使用full mode，或将Volatile函数写在distribution key后面。

  • 升级至最新版本。

P2

加载Table Group到计算组时，FE可能获取不全SE shard location信息，导致FixedFE写入失败，影响时长约1秒。

函数DDLReadService::DoGetTableGroupShards中碰到ShardInfos为空时使用了break而非continue，导致数据获取不全。

V1.1

  • V4.1.7

  • V4.0.24

  • 升级至最新版本。

P2

当array列变长类型超过64MB时进行攒批，报错Copy overflow with offset xx, length xx, and array length xx。

mutable array只reserve了一行，但append进来的array超过1行；当text列超过64MB时，builder大小被reserve成一行，没有考虑到最小值。

V4.0

  • V4.1.6

  • V4.0.21

  • 绕过方式：执行alter database xxx set hg_experimental_enable_batch_accumulator_v2=off;。

  • 升级至最新版本。

P2

用户执行SQL时阿里云账号名不能自动转换为ID，如GRANT USAGE ON SCHEMA public TO "ALIYUN$a"。

is_initdb被错误地视为true，未声明extern bool is_initdb;。

  • V2.2

  • V3.0

  • V3.1

  • V3.2

  • V4.0

V3.0.53

  • 绕过方式：避免使用账号名，直接用ID做相关操作。

  • 升级至最新版本。

P2

批量copy处理时共享内存可能写满，报错ERROR: Parse data from copy ecountered internal error或coredump（栈中有holo_copy或CopyReadLineText）。

copy批量模式将客户端数据按行数攒批写入共享内存，用户作业单条数据较大（每批约600MB），多连接同时写入时可能将共享内存用满，导致后续数据写入失败或读取侧因溢出读取到非法值导致进程崩溃。

V1.1

  • V4.1.5

  • V4.0.21

  • V3.2.31

  • 绕过方式：采取流式copy写入；或调小攒批条数hg_experimental_query_batch_size（默认8192），如alter user xx set hg_experimental_query_batch_size = 512;。

  • 升级至最新版本。

P2

Parquet读数组列时，因page index跳页导致报错。打开page index（默认打开），SQL读数组列且有谓词下推到parquet reader并因此有任意列的任意页被过滤时可能触发。

page index跳页逻辑与数组列读取存在兼容性问题，当谓词过滤导致页跳过时，数组列的读取状态未能正确同步。

V3.1

  • V4.1.5

  • V4.0.19

  • V3.2.29

  • V3.1.43

  • 绕过方式：关闭page index：set hg_experimental_enable_external_parquet_use_page_index = off;。

  • 升级至最新版本。

P2

Fixed plan模式下，INSERT ON CONFLICT语句中WHERE条件为常量时结果不正确。执行insert into a values(0,1) on conflict(id) do update set id = excluded.id, name = excluded.name where 1 = 0;时，id不冲突但写入0行。

当WHERE条件为常量表达式时，未能正确进行条件改写，导致符合条件的数据无法写入。

V4.0

  • V4.1.6

  • V4.0.24

  • 绕过方式：使用INSERT OR IGNORE语法，避免在ON CONFLICT表达式中使用常量条件。

  • 升级至最新版本。

P2

Parquet reader无法处理空row group，读到包含0行的row group时报错，错误信息被抛回用户侧。Hologres V3.1及以上版本可能表现为coredump，栈中包含hologram::spi::parquet::RowRange。

reader内部假设row group中一定包含数据（非0行），在处理空row group时，解析数据页返回eof时被忽略，导致错误处理逻辑被触发。

V3.0

  • V4.1.4

  • V4.0.19

  • V3.2.29

  • 绕过方式：用hiveqe执行query，设置GUC参数：set hg_experimental_force_access_dlf_paimon_via_hiveqe = on;或set hg_experimental_force_access_dlf_iceberg_via_hiveqe = on;或hg_experimental_enable_access_dlf_via_fse = off;。

  • 升级至最新版本。

P0

bulkload提交空文件导致flush失败。bulkload提交了一个file size为0的文件，导致后续的flush打开这个文件读meta时失败。

bulkload触发deletion compaction时，被pick的文件中所有行都被标记删除，产生空文件。

V3.1

  • V4.1.2

  • V4.0.18

  • V3.2.29

  • V3.1.43

  • 绕过方式：设置GUC参数并重导表：set hg_serverless_computing_run_compaction_before_commit_bulk_load = off;。

  • 升级至最新版本。

P2

二级索引包含bool类型时，Fixed plan写入报错。创建global index并insert时报错：ERROR: XX000: internal error: unexpected error, failed to write, detail: Unsupported type in fixed dispatcher.

fixed dispatcher不支持bool类型在二级索引中的写入。

V4.0.0

  • V4.0.16

  • V4.1.2

  • 升级至最新版本。

P2

Holo FDW跨实例查询失败。升级4.0后使用外表查询时报错：Fetch table group shards failed on meta proxy:Loading cached shard location value for table group[...] failed。

FDW加载缓存的shard location值时失败。

V4.0.6

  • V4.0.15

  • V4.1.1

  • 升级至最新版本。

P2

从脱敏表写入数据到含自增列的目标表时出现非预期行为。在Hologres V4.0及以前版本，从脱敏表写入到另一个表时，如果目标表存在自增列，会出现coredump或报错行为异常。

代码假设parsetree->targetList和rte_insert->insertedCols一一对应，但当目标表含有自增列时假设不成立。parsetree->targetList包含自增列和用户明确写入的列，而rte_insert->insertedCols只包含用户明确写入的列。

V3.1

  • V3.2.26

  • V4.0.14

  • V3.1.42

  • 绕过方式：不要使用自增列。

  • 升级至最新版本。

P2

Array Ref接口线程不安全导致coredump。从Hologres V2.2开始，worker级别shuffle和QE v2的shuffle逻辑中，多线程访问array->type时可能出现coredump，array的type字段变为非法值。

ArrayRef的获取type接口虽标记为const，但使用mutable关键字使成员变量type_可改。多线程同时获取type时可能破坏type_的control block，导致线程安全问题。

V3.1

  • V4.1.6

  • V4.0.21

  • V3.2.31

  • V3.1.45

  • 临时绕过：关闭worker级别shuffle和QE v2。set hg_experimental_enable_worker_level_connection = off; set hg_experimental_enable_qe_v2 = off;。

  • 升级至最新版本。

P2

已创建的Dynamic table执行alter definition加列时报错。base表为物理分区表、DT为逻辑分区表时，对DT执行alter definition报错：ERROR: New definition is not supported in incremental mode: Multiple partitions of table XXX is selected或ERROR: New definition is not supported in incremental mode: No partitions of table XXX is selected。

create流程中已关闭GUC忽略QO分区数检查，但alter definition流程未同步该逻辑。

V3.1

  • V3.1.40

  • V3.2.24

  • V4.0.12

  • V4.0.13

  • 绕过方式：设置GUC参数：set hg_experimental_check_selected_partition_table_number_for_dynamic_table = off;之后再执行alter definition。

  • 升级至最新版本。

P2

创建External Dynamic table时报主键重复错误。当External DT的select query中join或union多个相同表时，生成的base table list包含重复项，插入系统表时报错：ERROR: duplicate key value violates unique constraint "pg_holo_external_dynamic_table_dependencies_name_index"。

dt和external dt都存在该问题。dt的系统表没有主键所以插入重复记录未报错，但external dt的系统表有主键约束，不允许插入重复记录。

V4.0

V4.0.13

  • 升级至最新版本。

P2

char(n)类型数据执行聚合查询时报错。开启AQE后执行select col1, max(col2) from t1 group by col1时报错：hos_exception: Internal error: HGERR_code XX000 ExecuteQuery failed, last errmsg: syntax error at or near "4294967291"。

ORCA中对于输出结果为char类型的agg未推导type_modifier字段，导致agg结果的char类型type_modifier被置为-5（即4294967291）。开启AQE时尝试创建char(4294967291)类型字段，超出长度限制导致报错。

V3.1

  • V3.1.39

  • V3.2.24

  • V4.0.12

  • V4.0.13

  • 绕过方式：关闭AQE：alter database xxx set hg_experimental_enable_adaptive_execution = off;。

  • 升级至最新版本。

P2

view中包含无别名子查询时，snapshot SQL执行失败。在view的select语句中使用了subquery alias optional功能（子查询未指定别名）后，执行hg_dump_script生成的snapshot sql会报错：unnamed_subquery不存在。

pg从view rule中推导view definition sql时未强制给subquery指定别名。当用户的view中subquery alias未指定别名时，推导出的view definition sql也没有给subquery指定名字，但target list中却指定了名字，导致sql解析失败。

V4.0

  • V4.1.6

  • V4.0.12

  • 绕过方式：用户将这类view进行create or replace方式重建，给每个subquery都指定别名。

  • 升级至最新版本。

P1

Paimon DV表按PK group后出现重复记录。当Parquet文件中存在物理格式为FIXED_LEN_BYTE_ARRAY、逻辑格式为decimal且编码格式为plain的page，读取该列的record batch跨越页边界时，仅该record batch中页边界之后的数据会被错误放置于record batch开始处。

Parquet decoder放置数据时未加上偏移量，导致record batch跨越页边界时数据位置错误。

V3.1.0

  • V3.1.39

  • V3.2.23

  • V3.2.24

  • V4.0.12

  • 绕过方式：执行select hg_admin_command('set_global_flag', 'enable_create_decimal_array_v2 = true');。

  • 升级至最新版本。

P2

MC表切换成Common Table链路后，Auto Analyze获取不到表最新的last modified time信息。用户升级到Hologres V3.0.51后，查询外表时从普通链路改成Common Table链路后，OOM报错仍然存在。MC表三层模型情况下，common table链路获取的response中schema name会变成default而非Holo的project_name，导致Auto Analyze批量获取外表的last modified timestamp失败，外表收集不到变化信息。

common table链路与holo_native在三层模型处理上未对齐。fetcher->GetTables接口在三层模型情况下，holo_native返回的schema_name仍是project_name，但common table返回的schema_name会变成default，导致数据无法回填。

V3.0

  • V3.0.52

  • V3.1.39

  • V3.2.23

  • V3.2.24

  • 绕过方式：手工执行ANALYZE。

  • 升级至最新版本。

P2

Hologres使用CommonTable查询MC数据的时候，oct_get_partition_names接口有缓慢的内存泄漏。Hologres V3.1.22升级到Hologres V3.1.30后出现，内存长期来看存在持续缓慢上涨的情况。开启CommonTable对MC分区表进行高频查询时触发。

oct_get_partition_names接口存在缓慢的内存泄漏，长期累积导致内存持续上涨。

V3.0

  • V3.0.51

  • V3.1.36

  • V3.2.18

  • V4.0.7

  • 绕过方式：这个内存泄漏比较缓慢，当holo_worker内存较高的时候，可以重启内存高的pod来恢复，如果pod比较多，可以重启实例。

  • 升级至最新版本。

P1

Union all在hash join的probe侧，第一个孩子中hash join生成的runtime filter被推到第二个孩子中，导致查询结果数据缺失。

Runtime filter经过映射下推到union all的第二个孩子过程中，合并了第一个孩子中的RF，导致错误下推。

V3.1

  • V3.1.39

  • V3.2.23

  • V3.2.24

  • V4.0.12

  • 绕过方式：设置GUC参数：alter database set hg_experimental_enable_runtime_filter_push_thru_union_all=off;。

  • 升级至最新版本。

P2

曾经rename过或alter schema过的dynamic table，升级到Hologres V4.0.7及以上版本，无法自动刷新。报错：ExecuteQuery failed, last errmsg: Can not find dynamic table properties of XXX或relation "XXX" does not exist。

dynamic table需要在driver中定期从FE获取最新properties。代码从table driver转移到driver master时，漏掉了同步最新table name和schema name的代码，导致升级后使用首次创建时的名称无法刷新。

V4.0.7

  • V4.0.10

  • V4.0.13

  • 升级至最新版本。

P2

CTAS（Create Table As Select）在createstmt阶段执行QO优化时，存在影响性能的优化步骤。

CTAS语句在createstmt阶段走QO优化时，部分优化步骤不必要地影响了性能。

V4.0

  • V4.0.10

  • V4.0.13

  • 升级至最新版本。

P1

增量刷新的动态表使用ANY_VALUE函数聚合时计算结果不正确。基表字段只有一个值，但查询DT表出现多个值。

FinalizeStateRows时错误将result_array的生成放在循环体里面，该bug未CP到3.2版本。

V3.2

V3.2.24

  • 绕过方式：将该函数换成MIN/MAX函数，如select id, sum(col1), min(col2) from t1 group by id。

  • 升级至最新版本。

P2

查询外表时，从普通链路改成Common Table链路后，OOM报错增多。报错：ERROR: internal error: common table memory pool out of memory。

Common Table链路在Auto Analyze收集时权限有变化，系统无法获取表的last modified time，导致auto-analyze无法触发，统计信息未及时更新引发OOM。

  • V3.0.42

  • V3.1

  • V3.2

  • V4.0

  • V4.0.9

  • V3.1.38

  • V3.2.21

  • V3.0.51

  • V3.2.24

  • 绕过方式：手动执行ANALYZE。

  • 升级至最新版本。

P2

Dynamic table refresh同时打开多行事务时，走Serverless报错。

Patch将TG不存在的报错提前到FE检查，但未考虑Serverless特殊情况。在Follower计算组上执行无法自动路由的Serverless DML时会触发。

V4.0

  • V4.0.9

  • V4.0.13

  • 绕过方式：走DML自动路由（如赋予Leader计算组权限）；或连接Leader warehouse执行SQL或创建DT。

  • 升级至最新版本。

P2

Query OOM（内存溢出）。

shuffle的ec优先级被改低，导致CPU较满时抢不到时间片，build端获取数据较慢，runtime filter构建延迟，probe端读取过多数据导致RF过滤效率降低。

V4.0.x之后

  • V4.0.10

  • V4.0.13

  • 绕过方式：设置GUC参数：hg_experimental_enable_qe_v2 = on、hg_experimental_runtime_filter_wait_time_ms = 10000、hg_experimental_wait_for_all_runtime_filters = on。

  • 升级至最新版本。

P1

部分登录审计日志中client_addr字段为空。

Gateway汇报登录审计日志时额外调用getpeername获取客户端IP，若此时客户端连接已异常断开则无法获取。

支持登录审计日志的所有版本

V4.0.13

  • 升级至最新版本。

P2

使用preparestmt执行包含clustering key的查询时报错：ERROR: XX000: Dispatch query failed: internal error: DataType::STRING column range conjuncts should use string literal or parameter ref.

mask_md5是clustering key，在preparestmt时mask_md5 in (md5($1),md5($2))无法常量折叠，导致提取的clustering filter中带上了md5函数，后端无法解析该filter而报错。

V1.1

  • V3.1.37

  • V3.2.20

  • V4.0.8

  • V3.2.24

  • 绕过方式：不使用preparestmt；或将mask_md5 in (md5($1),md5($2))改为mask_md5 = md5($1) or mask_md5 = md5($2)。

  • 升级至最新版本。

P2

用户执行带limit的query或主动cancel早停时，小概率发生coredump，导致query执行失败，worker重启。

SplitFactory的Close函数中进行了资源释放操作，但没有使用自己的ExecutionContext，导致资源释放时机早于其他函数执行结束，引发coredump。

V3.2.4

  • V4.0.7

  • V3.2.19

  • V3.2.24

  • V4.0.13

  • 绕过方式：设置GUC参数：alter role all set hg_experimental_enable_qe_v2 = off;。

  • 升级至最新版本。

P2

TableGroup unload后Holoweb无法登录，元仓报错ERROR: 42704: Table group[bizp.bizp_tg_default] is not found in warehouse bdmp_api_warehoue。Gateway指标显示新建连接请求多、耗时高，短时间新建fixed fe连接数很多，消费binlog启动时拿锁时间久，并发多时会卡insert。

发生unload时，在旧的warehouse上的binlog/fixed plan等新请求在bhclient中会retry 27.5s。fixed fe上消费binlog是连接ec同步调用这个方法，当发生retry时会卡连接ec，导致fixed fe新建连接创建卡住，从而导致连接堆积。

V3.2

V4.0.8

  • 绕过方式：停止binlog消费任务，改Flink作业使用正确的warehouse消费；或用户侧登录Holoweb把未加载的table group load到目标计算组，如果Holoweb无法登录，需要找FE研发后台重启gateway。

  • 升级至最新版本。

P2

Hologres V3.1版本Dynamic Table开启auto refresh后，容器内存（监控尺度拉到7天级别）持续上涨，holo worker内存稳定但FE内存升高。重复执行hg_generate_query_options_for_dynamic_table时内存持续上涨。

UDF hg_generate_query_options_for_dynamic_table存在内存泄漏。UDF中new了一个HoloQmDispatcher对象，虽然使用shared_ptr，但DispatcherManager会将其放入以query_id为key的map中。代码创建的query_id不是UDF执行query的query_id，而是一个单独的query_id。正常query结束时应调用RemoveDispatcher(query_id)删除dispatcher，但代码中漏了这一步。DispatcherManager生命周期与conn进程绑定，导致dispatcher对象不断累积。

V3.1.0

  • V4.0.0

  • V3.1.26

  • V3.2.8

  • 绕过方式：在pg_stat_activity中找到并kill掉长连接；或注册cron job自动清理超过1小时的连接：SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE length(query) > 0 AND pid != pg_backend_pid() AND backend_type = 'client backend' AND state = 'idle' AND application_name = 'DynamicTableTableDriver' AND current_timestamp - backend_start > '1 hour';。

  • 升级至最新版本。

P2

实例中存在2个worker内存高于其他worker，且无shard倾斜。监控显示FE内存差距过大，从内存开始上涨时间点查询，存在长连接存活很久且执行了大量DDL（query_count > 1000）。

DDL执行流程中存在内存泄漏。QueryDesc对象的内存释放依赖query结束时MemoryContext的整体释放，但UtilityStmt（广义DDL）的内存分配在长生命周期的MemoryContext中，导致query级别MemoryContext释放时不会释放它，产生内存泄漏。

所有版本

  • V3.1.22

  • V3.2.5

  • V3.2.24

  • 绕过方式：关闭存在内存泄漏的长连接即可释放内存。可通过SQL排查：SELECT pid, session_id, count(*) as query_count, max(query_start) FROM meta_warehouse.query_info WHERE query_start > now() - '1 hour'::interval AND command_tag NOT IN ('INSERT','SELECT','DELETE','UPDATE') GROUP BY 1,2 ORDER BY 3 DESC LIMIT 20;。

  • 升级至最新版本。

2026年2月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

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值不参与计算。

说明

该函数在处理三个入参请求时，NULL值也会参与计算，与PostgreSQL行为一致。

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

  • V3.0.1

  • V3.1.1

  • V3.2.1

  • V3.0.46

  • V3.1.25

  • V3.2.24

  • 升级至最新版本。

2026年1月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

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>;

2025年缺陷

2025年12月

严重等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

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;

  • 升级至最新版本。

2025年11月

等级

报错/问题描述

缺陷原因

出现版本

修复版本

规避建议

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

  • 升级至最新版本。

2025年10月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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后的账单。

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

2025年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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

升级至最新版本。

2025年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级至最新版本。

2025年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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。

  • 推荐方式：

    升级到最新版本。

2025年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

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

2025年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2025年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2025年02月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

  • 升级到最新版本。

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

2025年01月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

说明

升级到新版本后，无需配置OSS Endpoint即可查询成功。

2024年缺陷

2024年12月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

说明

不建议全量刷新模式开启Binlog，每一次全量刷新都相当于在执行INSERT OVERWRITE，会导致Binlog不完整。

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;

2024年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

说明

升级完成后，进行跨库查询时，如果外表中存在roaringbitmap类型，将直接报错，提示不支持该类型。

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及以上版本。

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

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

2024年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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版本。

升级到最新版本。

2024年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年05月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2024年02月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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类型。

  • 升级到最新版本。

2024年01月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

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及以上版本。

升级到最新版本。

2023年历史缺陷

2023年12月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

修改实例的Shard replica数后，实例出现短暂重启。示例SQL：

--实例出现短暂重启
CALL HG_CREATE_TABLE_GROUP ('tg', 1);
CALL HG_UPDATE_DATABASE_PROPERTY ('default_table_group', 'tg');
CALL hg_set_table_group_property ('tg', 'replica_count', '2');

修改实例的Shard replica数后，元数据未被更新，导致实例出现短暂重启。

出现版本：

  • V2.1.1至V2.1.10版本。

  • V2.0.33及以下版本。

修复版本：

  • V2.1.11及以上版本。

  • V2.0.34版本。

升级到最新版本。

P2

使用存储过程（hg_insert_overwrite）导入数据失败后，临时表未被清理。

hg_insert_overwrite在执行过程中会创建一张临时表，目前未实现临时表清理机制，导致任务失败后，临时表未被清理。

出现版本：

V2.0.19及以下版本。

修复版本：

V2.0.30及以上版本。

  • 手动删除临时表

  • 升级到最新版本

P2

通过Fixed Plan将数据写入Hologres的DECIMAL类型列，如果待写入数据为负数，且最小有效小数位与目标字段的小数精度相差19位以上，可能出现数据错误。示例SQL：

CREATE TABLE fixed_plan_decimal (col decimal(38,19));

-- 待写入数据为负数，其最小有效位为个位，与目标字段的小数精度相差19位，触发写入数据错误
INSERT INTO fixed_plan_decimal VALUES (-1.000000000);

-- 写入结果为7922816250.4264337593543950336
SELECT * FROM fixed_plan_decimal;

Fixed Plan链路对DECIMAL类型精度处理有误，导致数据错误。

出现版本：

V2.1.11及以下版本。

修复版本：

V2.1.12及以上版本。

说明

修复后，Fixed Plan链路将与非Fixed Plan链路行为一致。

  • 数据写入时，显式指定数据精度，如：-1.000000000::decimal(38,19)。

  • 升级到最新版本。

P1

实例开启了Binlog，升级到V2.1.9版本后，CPU使用率显著升高。

对于开启Binlog的实例，升级到V2.1.9版本后，在某些场景上Binlog未能正确抓住错误，导致发生错误后无法正常退出，打印较多日志，引起CPU使用率升高。

出现版本：

V2.1.1至V2.1.9版本。

修复版本：

V2.1.10及以上版本。

升级到最新版本。

2023年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

使用var_samp函数计算方差，输入数据类型为DECIMAL时结果不正确。示例SQL：

CREATE TABLE t1(f1 decimal(38,18));
INSERT INTO t1 VALUES (123),(234),(456);

--decimal类型结果错误
SELECT var_samp(f1) FROM t1;
--返回结果
var_samp   
--------------
 0.2382402695

--转成int类型，结果正确
SELECT var_samp(f1::int) FROM t1;
--返回结果
var_samp     
------------------
 28749.0000000000

var_samp方差计算函数在计算DECIMAL类型时，类型转换错误，导致结果不正确。

出现版本：

V2.0.27及以下版本。

修复版本：

V2.0.28及以上版本。

升级到最新版本。

2023年10月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用date_part函数时要提取的字段为大写报错：error：unsupport extract type xxx。示例SQL如下：

SELECT date_part('HOUR',ts) FROM tt;
--error: unsupport extract type [HOUR]

优化器未能正确识别date_part函数中大写字段，导致查询报错。

出现版本：

V2.0.1至V2.0.25版本。

修复版本：

V2.0.26及以上版本。

升级到最新版本。

P2

使用&&连接Array时查询报错：Unexpected expr type in array expr:145，示例SQL如下：

CREATE TABLE test (
  channel_info text
);
SELECT regexp_split_to_array(LOWER('TMK'),',') && array[(regexp_split_to_array(LOWER(channel_info),'-'))[2]]  FROM test;

--error: Unexpected expr type in array expr:145

&&的执行引擎是HQE，当&&连接Array时，优化器对Array处理有误，导致执行计划错误，从而查询报错。

出现版本：

V2.0.25及以下版本。

修复版本：

V2.0.26及以上版本。

升级到最新版本。

P2

对于分区表，with语句选中0个分区时返回的结果中列的别名（alias）错误，示例SQL如下：

CREATE TABLE t0_parent(ds text, v1 bigint, v2 bigint, v3 bigint) PARTITION BY list (ds);
CREATE TABLE t0_child1 PARTITION OF t0_parent FOR VALUES IN ('20230915');
CREATE TABLE t0_child2 PARTITION OF t0_parent FOR VALUES IN ('20230916');

--查询语句，选中了0个分区
WITH cte1 AS (
  SELECT v1, v2, v3 FROM t0_parent
),
    cte2 AS (
      SELECT v1, v2 FROM cte1 WHERE v3 = 1 AND v3 = 2
    )
    SELECT v2 AS vb, v1 AS va FROM cte2 limit 1;

--错误结果，别名错误 
 v2 | v1 
----+----

--正确结果，别名正确
vb | va 
----+----

对于分区表的with cte查询，当SQL中选中了0个分区时，优化器QO在生成执行计划时会把0个分区节点给优化掉，导致返回结果不正确，从而列的别名丢失。

出现版本：

V2.0.25及以下版本。

修复版本：

V2.0.26及以上版本。

升级到最新版本。

P2

case when语句中有使用DECIMAL类型，且case when语句中有走PQE的函数，导致结果报错：

error: column with id 0 has type decimal(38, 10) but ReadColumn returns array Array(type=decimal(20, 4) length=1 null_count=0 [1.0000]).

case when中有DECIMAL类型时，经过PQE的函数，DECIMAL的精度未被正常转换，导致结果精度无法对齐而报错。

出现版本：

V2.0.23及以下版本。

修复版本：

V2.0.24及以上版本。

升级到最新版本。

P2

父子表在不同Schema，往子表导入数据时报错：Can't find parent table for table name。示例SQL如下：

CREATE schema haha;
CREATE TABLE haha.p(
  a text not null, 
  b int not null
) PARTITION BY LIST(a);
CREATE TABLE public.c1 PARTITION OF haha.p FOR VALUES IN('v1');

insert into public.c1 SELECT 'v1', generate_series(0,100);
--error:Can't find parent table for table name

在Hologres中，父表和子表可以允许不在同一个Schema中，当前父子表不在同一个Schema执行INSERT操作时，未正确判断父子表关系，导致报错。

出现版本：

V2.0.23及以下版本。

修复版本：

V2.0.24及以上版本。

升级到最新版本。

P2

行存表设置Clustering Key和PK不一致，且没有显式设置TTL时，通过insert on conflict do update的bulkload离线导入后，查询时出现主键重复。示例SQL如下：

--建表语句
BEGIN ;
CREATE TABLE test (
  id integer,
  phone_number text,
  create_time text
  ,PRIMARY KEY (id)
);
CALL set_table_property('test', 'orientation', 'row');
CALL set_table_property('test', 'storage_format', 'sst');
CALL set_table_property('test', 'clustering_key', 'create_time:asc');
CALL set_table_property('test', 'distribution_key', 'id');
CALL set_table_property('test', 'time_to_live_in_seconds', '3153600000');
COMMIT ;


--查询时，主键重复
SELECT * FROM test;
id | phone_number |create_time
---|--------------|-----------
1  | 134xxxx      | 2023-11-06 19:25:42.483287+08
1  | 134xxxx      | 2023-11-06 19:25:42.483287+08

行存表insert on conflict do update的原理是标记delete+insert，当行存表的PK和Clustering Key不一致时，标记的delete文件未被正确Compaction，从而导致主键重复。

出现版本：

V2.0.22及以下版本。

修复版本：

V2.0.23及以上版本。

  • 将行存表的PK和Clustering Key改为一致，或者设置表为列存表。

  • 升级到最新版本。

P2

多个count distinct对执行array_to_string(array_sort xxx))后的列group by报错：ORCA failed to produce a plan : No plan has been computed for required properties。示例SQL如下：

create table t1 (f1 int , f2 int , f3 int , f4 text[]);

SELECT 
f1,f5,
count(distinct f2),
count(distinct f3)
FROM 
(
  SELECT f1,f2,f3,array_to_string(array_sort(f4),',')as f5 FROM t1
)tt
group by f1,f5;

count distinct会产生CTE，array_sort函数不支持CTE inline，导致执行计划推导错误，从而SQL报错。

出现版本：

V2.0.22及以下版本。

修复版本：

V2.0.23及以上版本。

升级到最新版本。

P2

执行drop server之后，部分查询卡住。

执行drop server后，FE节点间未能正常Replay，导致节点间版本不一致，从而查询卡住。

出现版本：

V1.3.40至V1.3.51版本。

修复版本：

V1.3.52及以上版本。

升级到最新版本。

2023年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用Proxima向量索引，当插入null向量并且不走Fixed Plan时，写入就会报错：internal error: check condition "and_handle_null" assert failed，示例SQL如下：

BEGIN;
CREATE TABLE t (
  vector float4[] CHECK (array_ndims(vector) = 1 AND array_length(vector, 1) = 3)
);
CALL SET_TABLE_PROPERTY ('t', 'proxima_vectors', '{"vector":{"algorithm":"Graph","distance_method":"SquaredEuclidean"}}');
END;

set hg_experimental_enable_fixed_dispatcher = off;

-- 插入一个null向量
INSERT INTO t values (null);
-- ERROR:  internal error: check condition "and_handle_null" assert failed.

非Fixed Plan模式下，写入null的向量值，导致CHECK (array_ndims(vector) 时系统不匹配，从而报错。

出现版本：

V2.0.21及以下版本。

修复版本：

V2.0.22及以上版本。

升级到最新版本。

P1

MaxCompute项目开启存储加密后，Hologres外部表查询MaxCompute数据偶发报错：query next FROM foreign table executor failed或者Channel is empty或者internal error: Connect timeout。

Hologres在 V2.0.15版本为修复读MaxCompute加解密的密钥传递异常问题，引入了多线程内存写坏问题，在MaxCompute外表处于Schema Evolution状态时，会引发SQE组件偶发Coredump重启，引起应用层访问外部表偶发出现报错。

出现版本：

V2.0.15至V2.0.20版本。

V1.3.61至V1.3.62版本

修复版本：

V2.0.21及以上版本。

升级到最新版本。

P2

具有not null属性的字段使用string_agg处理时报错：Column column0 should be non-nullable but the values contain 1 nulls，示例SQL如下：

create table test(id int not null, msg text not null);    insert into test values (1, 'b');SELECT count(distinct id), string_agg(distinct id::text) FROM test where msg = 'a';

string_agg的输出可以是null，但优化器QO会根据他处理的字段属性进行推导结果是否为null。当字段为not null时，QO会推导string_agg的结果不能为null，导致结果错误，从而出现报错。

出现版本：

V2.0.20及以下版本。

修复版本：

V2.0.21及以上版本。

升级到最新版本。

P2

当实例的Table Group和Shard Count较多时（Shard Count大于100），Shard Count因Worker挂掉等原因分配不均，使用Rebalance命令后仍然不均匀。

当实例的Table Group和Shard Count较多时（Shard Count大于100），Rebalance命令在重新分配Shard时不准确，导致仍然不均匀。

出现版本：

V2.0.20及以下版本。

修复版本：

V2.0.21及以上版本。

升级到最新版本。

P2

表字段有4字节长度的UTF-8数据，使用substring处理时结果错误（FROM 表），单独使用substring处理4字节长度的UTF-8数据，结果正确。示例SQL如下：

-- 返回结果为3，正确SELECT length(substring (E'\U0001F345' || '23456789', 1, 3));-- substring FROM 表时，结果错误create table t (emoji text);insert into t values (E'\U0001F345' || '23456789');-- 返回结果为1，结果错误，实际应该为3SELECT length(substring(emoji, 1, 3)) FROM t;

目前实现中，substring只支持了3字节长度的UTF-8数据，导致从表数据使用substring时结果出错。

出现版本：

V2.0.19及以下版本。

修复版本：

V2.0.20及以上版本。

升级到最新版本。

P2

开启Binlog消费后，CPU消耗显著增加。

由于系统默认参数设置不合理，在消费Binlog时，产生了高频的系统日志，造成CPU消耗增加。

出现版本：

V2.0.17-V2.0.19。

修复版本：

V2.0.20及以上版本。

升级到最新版本。

P2

string_agg或array_agg在有agg filter的情况下结果错误，示例SQL如下：

  • DDL和导入数据：

    create table test(x text, y int);insert into test values(null, 1), (null, 2),(null, 1), (null, 2);

  • 查询1：

    SELECT array_agg(x) filter (where x is not null) FROM test group by y;sql--预期返回结果[null][null]--实际返回结果，结果错误{null}{null}

  • 查询2：

    SELECT array_agg(x) filter (where x is  null) FROM test group by y;--预期返回{null,null}{null,null}--实际返回，结果错误{null,null}{null}

string_agg或array_agg在有agg filter的情况下，未能正确处理filter，导致结果错误或者filter结果不稳定。

出现版本：

V2.0.18及以下版本。

修复版本：

V2.0.19及以上版本。

升级到最新版本。

P2

具有not null属性的字段使用array_agg filter出来的结果有null时，导致实例出现短暂重启，示例SQL如下：

create table bbb(x int not null, y int);insert into bbb values (1, 1);SELECT array_agg(x) filter (where x > 1) FROM bbb group by y;

使用array_agg filter时，如果这个字段本身是not null，那么QE会将结果推导成not null，而实际结果中有null，导致与推导结果冲突，实例出现coredump。

出现版本：

V2.0.18及以下版本。

修复版本：

V2.0.19及以上版本。

升级到最新版本。

P1

使用Proxima时，将min_flush_proxima_row_count参数设置为0导致实例重启。

对于Hologres存储引擎SE，min_flush_proxima_row_count参数值必须大于0，当把min_flush_proxima_row_count设置为0时，SE检验不通过，导致实例重启。

出现版本：

V2.0.18及以下版本。

修复版本：

V2.0.19及以上版本。

升级到最新版本。

P2

开启自动创建分区后，将表移动至另一个Schema，并在原Schema下新建同名表时报错：ERROR: auto_partitioning.time_unit could only be specified once，示例SQL如下：

--开启自动分区begin;CREATE TABLE ads.test (  olap_date integer NOT NULL default 0,  pk text NOT NULL default ''::text,  sid text  ,PRIMARY KEY (olap_date, pk))  PARTITION BY LIST (olap_date);CALL set_table_property('ads.test', 'auto_partitioning.enable', 'true');CALL set_table_property('ads.test', 'auto_partitioning.time_unit', 'day');CALL set_table_property('ads.test', 'auto_partitioning.time_zone', 'PRC');CALL set_table_property('ads.test', 'auto_partitioning.num_precreate', '4');CALL set_table_property('ads.test', 'auto_partitioning.num_retention', '33');CALL set_table_property('ads.test', 'auto_partitioning.num_hot', '15');commit;--切换表的schemaalter table test set schema to public;--重新创建同名表begin;CREATE TABLE ads.test (  olap_date integer NOT NULL default 0,  pk text NOT NULL default ''::text,  sid text  ,PRIMARY KEY (olap_date, pk))  PARTITION BY LIST (olap_date);CALL set_table_property('ads.test', 'auto_partitioning.enable', 'true');CALL set_table_property('ads.test', 'auto_partitioning.time_unit', 'day');CALL set_table_property('ads.test', 'auto_partitioning.time_zone', 'PRC');CALL set_table_property('ads.test', 'auto_partitioning.num_precreate', '4');CALL set_table_property('ads.test', 'auto_partitioning.num_retention', '33');CALL set_table_property('ads.test', 'auto_partitioning.num_hot', '15');commit;ERROR: auto_partitioning.time_unit could only be specified once

开启自动创建分区后，对原表切换Schema，自动分区的配置未能一起切换，导致在原Schema下创建同名表时，自动分区配置冲突，从而出现报错。

出现版本：

V2.0.18及以下版本。

修复版本：

V2.0.19及以上版本。

升级到最新版本。

2023年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用Concat函数入参为单列时报错：Function concat node must have at least 2 arguments but it only has 1。示例如下：

create table aaa(x text);insert into aaa values ('11111111');SELECT concat(x) FROM aaa;HGERR_msge internal error: Function concat node must have at least 2 arguments but it only has 1

低版本不支持Concat函数入参为单列，导致报错。

出现版本：

V2.0.17及以下版本。

修复版本：

V2.0.18及以上版本。

建议升级到最新版本。

P1

分区表开启冷存后，对分区父表执行alter schema操作，例如add column，导致分区子表转化为冷存动作不符合预期，具体可能有如下几种：

  • 部分分区子表转为冷存的状态持续为transferring。

  • 预期应该转化为冷存的子表，未正常转换，例如设置10天前子表为冷存，但是存在10天前子表是热存。

  • 已经为冷存的子表，查看存储时仍然按照热存的形式存储。

对于分区表设置冷存的场景，如果父表执行alter schema操作，会同时对子表生效，导致分区子表的存储属性在FE节点与元数据管理器SM不一致（子表在FE上存储为冷存，SM为其他模式），从而导致子表的冷存动作不符合预期。可以通过如下SQL获取不符合预期的冷存表：

SELECT db_name, schema_name, table_name FROM hologres.hg_table_info where collect_time::date = date '20230901' and table_meta::json#>>'{table_storage_mode}' = 'cold' and hot_storage_size > 0 order by table_name;

出现版本：

V2.0.17及以下版本。

修复版本：

V2.0.18及以上版本。

  • 在一个事务内修改已经转换为冷存子表的存储属性，示例如下：

    begin;call set_table_property('schema.<冷存子表名>', 'storage_mode', 'hot');call set_table_property('schema.<冷存子表名>', 'storage_mode', 'cold');commit;

  • 建议升级到最新版本。

    说明

    升级后，对于升级前的存储冷存子表还需要再做一次存储属性订正。

P2

只读从实例无法消费Hologres Binlog。

只读从实例某项默认属性变更导致。

出现版本：

V1.3和V2.0早期版本。

修复版本：

V1.3.61、V2.0.17及以上版本。

建议使用主实例消费Hologres Binlog，或升级到最新版本。

P2

某列和不同类型列做比较且用or连接时，如：col::type = const1::type1 or col::type = const2::type2，导致结果为空或者不符合预期。示例SQL如下：

create table t (a date, b timestamp, c text, d int);--a是date类型，or后转成了timestamp类型，导致结果不符合预期SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = timestamp '2023-06-14';--or连接的字段类型不一致SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = '2023-06-14';

or连接的字段类型不一致时，优化器QO在生成执行计划时，没有将类型对齐，导致最终输出结果与预期有差异。

出现版本：

V1.3.59及以下版本和

V2.0.14及以下版本。

修复版本：

V1.3.60及以上版本和V2.0.15及以上版本。

建议升级到最新版本。

P2

主从实例，执行HG_MOVE_TABLE_TO_TABLE_GROUP或者设置表为readonly，有一定概率会触发从实例不可用。

由于从实例启动了Lazy Open机制，在主实例执行Resharding或者手动设置readonly为true后，并再次写入数据后，主从实例Shard状态存在不一致，造成从实例不可用。

出现版本：

V1.3.42至V2.0.16版本。

修复版本：

V2.0.17及以上版本。

  • 如果需要执行Resharding或者设置表只读，可以首先在从实例执行以下命令，提前关闭Lazy Open机制。

    SELECT hg_admin_command('set_global_flag', 'enable_dynamic_close_tablet=false');    SELECT hg_admin_command('set_global_flag', 'enable_lazy_open_tablet=false');

    。并需要设置完重启一次实例，新配置会引起内存水位有一定程度上升。

2023年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

使用PQE引擎查询时报错：

ERROR: status { code: SERVER_INTERNAL_ERROR message: "query next FROM pg executor failed FROM xxx: ERPC_ERROR_CONNECTION_CLOSED, reason: Drain packet failed, peer address:xxx" }

PQE进程在处理SQL请求时存在概率性缺陷，可能导致进程泄漏。当泄漏的进程数量达到512上限时，该实例将无法处理任何新的发送到PQE进程的查询请求。

出现版本：

V2.0.1至V2.0.11版本。

修复版本：

V2.0.12及以上版本。

建议升级到最新版本。

P2

共享集群读取ODPS加密数据报错：

error query next FROM foreign table executor failed ,pangu：//xxxx validate userinfao fail xxxx。

共享集群不支持加密数据。

出现版本：

V2.0.15及以下版本。

修复版本：

V2.0.16及以上版本。

建议升级到最新版本。

P2

使用备份恢复功能，原实例中有冷存表，且冷存表有频繁写入，备份失败。

冷存表有频繁写入时，数据会一直执行compaction，备份恢复使用的是不停机备份，compaction一直无法完成，导致shard之间的version一直无法对齐，备份获取不到shard最新状态，从而失败。

出现版本：

V2.0.15及以下版本。

修复版本：

V2.0.16及以上版本。

  • 将有频繁写入的冷存表转换为热存表再进行备份，转热存操作请参见数据分层存储。

  • 建议升级到最新版本。

P2

查询PQE的SQL手动cancel/系统超时cancel后，实例出现短暂重启。

PQE的SQL比较耗费资源，当SQL被系统超时cancel/手动cancel，没有被正常cancel，导致出现空指针，实例coredump。

出现版本：

V2.0.12至V2.0.14版本。

修复版本：

V2.0.15及以上版本。

建议升级到最新版本。

P2

case when查询中有array[]类型，查询报错：

Filter has x rows but length of columns is y。

case when处理array[]类型的字段时，会丢失array[]内的一些数据，导致查询报错。

出现版本：

V2.0.10及以下版本。

修复版本：

V2.0.11及以上版本。

建议升级到最新版本。

P2

对开启Binlog的表执行DROP操作后，实例有重启过，重启后实例存储并没有下降，监控的存储比pg_database_size查询结果多。

开启Binlog的表DROP后，实例重启导致表Binlog的目录没有被正常删除，从而导致存储未下降。

出现版本：

V2.0.12及以下版本。

修复版本：

V2.0.13及以上版本。

建议升级到最新版本。

P2

建表时指定distribution key为asc/desc顺序，导致查询报错/实例短暂重启。示例如下：

BEGIN ;CREATE TABLE test(a int);CALL set_table_property('test', 'distribution_key', 'a:asc');COMMIT ;

distribution key不支持指定asc/desc顺序，导致FE执行DDL时replay失败，从而出现coredump或者查询/写入对应表报错。

出现版本：

V1.3.55及以下版本。

修复版本：

V1.3.56及以上版本。

  • 创建distribution key时不指定asc/desc顺序。

  • 升级到最新版本解决coredump问题，建表时指定distribution key的asc/desc将会报错invalid distribution column: xx:asc。

2023年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

SLPM模式下，通过slpm_alter_view_owner函数开启在不同的Schema下建两个同名View，报错：ERROR: more than one row returned by a subquery used as an expression。示例SQL如下：

call slpm_enable();call slpm_enable_multi_schema_view();create schema test_schema;create table tb1(id int);create view public.v1 as SELECT * FROM public.tb1;create view test_schema.v1 as SELECT * FROM public.tb1;

SLPM模式下，跨Schema创建视图会引用pg_class系统表，当不同Schema下有同名View时，pg_class里有relname列重复，子查询查出来不止一行，从而导致结果错误。

出现版本：

V2.0.3至V2.0.9版本。

修复版本：

V2.0.10及以上版本。

建议升级到最新版本。

P2

开启冷存后，只读从实例访问冷存表，实例出现短暂重启。

当前版本只读从实例配置缺少冷存相关的环境变量，因此当只读从实例访问冷存表时报错。

出现版本：

V1.3.54及以下版本。

修复版本：

V1.3.55及以上版本。

  • 将冷存表转成标准存储表。

  • 建议升级到最新版本。

P2

Hologres实例升级 V1.3版本后在MaxCompute中创建Hologres外部表，通过双签名方式访问华东2（上海）和美国（弗吉尼亚）地域的Hologres实例时查询报错：

ERROR: pooler: xxxx: authentication failed。

华东2（上海）和美国（弗吉尼亚）地域升级后因环境配置错误，导致缺少MaxCompute访问Hologres的双签名账号鉴权，导致MaxCompute查Hologres时出现鉴权错误。

出现版本：

V1.3.54及以下版本。

修复版本：

V1.3.55及以上版本。

建议升级到最新版本。

P2

Hologres实例升级 V1.3版本后华东2（上海）和美国（弗吉尼亚）地域通过如下命令查看到单节点连接数上限不是128。

show max_connections;

华东2（上海）和美国（弗吉尼亚）地域升级后因环境配置错误，导致单节点最大连接数实际值与默认值128不同。

出现版本：

V1.3.54及以下版本。

修复版本：

V1.3.55及以上版本。

建议升级到最新版本。

P2

开启数据脱敏后，查询SQL使用CTE+union脱敏字段，导致查询报错：

ERROR: pooler: xxxx: remote server read/write error yy。示例如下：

set hg_anon_enable = on;create table if not exists test_anon_cte(id text);security label for hg_anon on column test_anon_cte.id is 'hash';with tt2 as (SELECT * FROM test_anon_cte) SELECT count(1) FROM tt2 where id != 'a' group by id union all SELECT count(1) FROM tt2 where id != 'b' group by id;

开启数据脱敏后，脱敏字段不支持union all，在CTE+union的情况下，最外层查询出现空指针，导致实例出现coredump，从而查询报错。

出现版本：

V1.3.51及以下版本。

修复版本：

V1.3.52及以上版本。

建议升级到最新版本解决实例coredump，但脱敏字段不支持union，查询会报错UNION is not supported on security item。

P2

Hologres从V1.1版本升级至V1.3版本后，cast array to text的结果中，会出现转义符号（\），示例如下：

create table arrary_to_text (  a text, b text, c text);insert into arrary_to_text values ('7416461', 'czzzzz', '2023-04-16 23:13:34');SELECT CAST(ARRAY_AGG(CONCAT('[','"', a,'"',',','"', b,'"',',','"', c,'"',']')) AS TEXT) AS list_vin FROM arrary_to_text limit 1;--1.3最新版本的返回结果"{"[\"7416461\",\"czzzzz\",\"2023-04-16 23:13:34\"]"}"--1.1版本返回结果"{"["7416461","czzzzz","2023-04-16 23:13:34"]"}"

Hologres V1.3.51以下的版本对cast array to text的转换支持不完善，未添加转义符号（\）。从V1.3.51版本开始，Hologres完善了cast array to text的支持，将行为保持与PostgreSQL标准协议一致，查询结果相比老版本结果中将会有转义符号（\），因此结果不一致是符合预期的。

出现版本：

V1.3.50及以下版本。

修复版本：

V1.3.51及以上版本。

结果多了转义符号（\）是符合预期的。

2023年05月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

执行包含Nested Loop Join的SQL报错：Schema has 1 fields but 2 are expected。示例SQL如下：

SELECT "_"."table_name"    FROM "public"."test" "_"    where "_"."table_name" = 'hello'     and (case when lower("_"."user_id") is not null        then lower("_"."user_id")        else ''        end) = 'ssss';

Hologres的Nested Loop Join输出列包含Outer和Inner，需要额外的project来指定输出的列，当前版本的Hologres优化器会将多余的project优化掉，导致表的列对不齐，从而查询报错。

出现版本：

V1.3.45及以下版本。

修复版本：

V1.3.49及以上版本。

建议升级到最新版本。

P2

TEXT类型数据转换成JSON类型时，如果TEXT类型的数据不符合标准JSON格式，也会被转成JSON类型。示例SQL如下：

create table test1(data text);insert into test1 values('{"a","b"}');SELECT data::json FROM test1;--错误的结果：{"a","b"}

正确的结果应该是报错：invalid input syntax for type json" detail: "Expected \":\", but found \",\"."。

执行text::json类型转换时，::json被处理成了cast，导致执行引擎QE触发JSON数据格式校验，导致数据被错误地转换成了JSON类型数据。

出现版本：

V1.3.20至V1.3.46版本。

修复版本：

V1.3.47及以上版本。

建议升级到最新版本。

P2

使用to_number函数（返回类型是DECIMAL），再将结果转换成STRING类型，后续的计算结果错误。示例SQL如下：

create table test(x text);insert into test values ('0');SELECT (to_number(x, '9') || ' days')::interval FROM test;结果为：-------0.E-10 days

在Hologres中，to_number会将0.0000000000转换成TEXT类型，然后变成科学计数法，计算引擎QE对于科学计数法目前处理不当，导致查询结果不正确。

出现版本：

V1.3.44及以下版本。

修复版本：

V1.3.46及以上版本。

建议升级到最新版本。

P2

读取MaxCompute Cluster、Cfile等特殊类型的表时，相比读取普通MaxCompute表，查询变慢。

当前版本读取MaxCompute Cluster 、Cfile时，Hologres的计算引擎会将读取的外表小文件拆分成更小的文件，导致单次查询的文件变多，因此查询变慢。

出现版本：

V1.3.20至V1.3.40版本。

修复版本：

V1.3.45及以上版本。

建议升级到最新版本。

2023年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

修改表Schema时（如修改TTL、Bitmap、Dictionary等），实例出现重启。如修改表的TTL的SQL示例如下：

call set_table_property('tablename', 'time_to_live_in_seconds', '946080');

实例从V1.1等低版本升级上来，导致系统中存在部分表历史版本Schema元数据有缺失，这部分缺失信息在对应表完成Flush或Compaction操作之后可能需要被访问，当前版本对Schema缺失信息处理不当，触发实例coredump。

出现版本：

V1.3.20至V1.3.44版本。

修复版本：

V1.3.45及以上版本。

建议升级到最新版本。

P2

使用早于1970年1月1日的timestamptz数据时，函数to_char(to_timestamp(hour))的返回结果会比实际时间少1小时，示例SQL如下：

create table t (a int);insert into t values (2);SELECT to_char(to_timestamp(a || '', 'HH24'), 'HH24:00:00') FROM t;

执行结果是：01:00:00，实际结果应该是02:00:00。

执行引擎在时间戳处理过程中，时间精度转化错误，导致结果错误。

出现版本：

V1.3.20至V1.3.43版本。

修复版本：

V1.3.44及以上版本。

建议升级到最新版本。

P2

SQL中带有JSONB类型转NUMERIC类型，且NUMERIC没有指定精度，查询报错：HGERR_msge numeric field overflow HGERR_detl A field with precision 0, scale 0 must round to an absolute value less than 1. HGERR_ctxt func_name:jsonb_numeric HGERR_end。示例SQL如下：

create table t1(f1 jsonb);insert into t1 values('1.1');SELECT f1::numeic FROM t1;

JSONB类型转NUMERIC类型未指定精度，优化器QO生成的执行计划没有给出默认精度，QE在执行的时候将NUMERIC转换为DECIMAL的时候对于没有指定精度的情况，默认值是0,0。因此无法运行导致报错。

出现版本：

V1.3.20至V1.3.41版本。

修复版本：

V1.3.42及以上版本。

  • JSONB类型转NUMERIC类型时指定精度。

  • 建议升级到最新版本。

P2

查询OSS数据湖数据时，报错：query next FROM foreign table executor failed, Failed to call iterateForeignScan: ArrayIndexOutOfBoundsException。

读取OSS数据时，Hologres数据湖查询引擎出现内存泄露，导致查询报错。

出现版本：

V1.3.20至V1.3.41版本。

修复版本：

V1.3.42及以上版本。

建议升级到最新版本。

2023年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

union all两个Decimal字段时，如果Decimal字段的精度不一致，查询报错：NUMERIC precision 65535 must be between 1 and 1000。示例SQL如下：

create table t1(a int ,b numeric(38,0), c bigint);create table t2(a int ,b numeric(38,0), c numeric(30,0));SELECT b / power(10, 18),c FROM t1UNION allSELECT a / power(10, a), c FROM t2

当union all两边的Decimal精度不一致时，QO未做精度对齐，导致执行时QE发现精度不一致，从而查询报错。

出现版本：

V1.3.20至V1.3.40版本。

修复版本：

V1.3.41及以上版本。

建议升级到最新版本。

P2

在同一个事务内，对已经存在的分区父表执行call set_table_property命令报错：SET_TABLE_PROPERTY and CREATE TABLE statement are not in the same transaction for table 。示例SQL如下：

--示例分区父表存在的情况下，执行如下sql：BEGIN;CREATE TABLE IF NOT EXISTS "public".test ( "parent_node_id" text, "parent_node_name" text, "is_leaf" text, "node_flag" text, "ds" text) PARTITION BY LIST(ds);CALL SET_TABLE_PROPERTY('"public".test', 'orientation', 'row');COMMIT;

在Hologres V1.3.38之前的版本，当分区父表存在时，使用set_table_property命令设置的属性与原表相同时，SQL会被自动忽略。在Hologres V1.3.38版本加强了对set_table_property设置属性的校验，原则上不允许对已经存在的表修改部分属性，比如orientation、distribution_key、clustering_key等属性，如果修改则会报错。

出现版本：

V1.3.38至V1.3.40版本。

修复版本：

V1.3.41及以上版本。

建议升级到最新版本。

说明

升级后将会保持与V1.3.38之前的版本行为一致，即如果表存在，修改表属性时如果属性相同则忽略掉SQL。

P2

to_date、to_char、to_timestamp函数在处理有前缀空格的数据时查询报错：HGERR_detl Field requires 4 characters, but only 0 could be parsed。示例SQL如下：

CREATE TABLE test2 (x text);INSERT INTO test2 VALUES (' 2022 03');SELECT to_date(x, 'YYYYMM')FROM test2;

当数据有前缀空格时，to_date、to_char、to_timestamp函数对空格处理有误，导致数据转换失败，从而查询报错。

出现版本：

V1.3.20至V1.3.40版本。

修复版本：

V1.3.42及以上版本。

  • 修改SQL处理前缀空格，示例：to_char(year, 'FM9999') 。

  • 建议升级到最新版本。

2023年02月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

rb_build函数带表名时报错：Not support calling pg udf for type (23, LIST)，示例SQL如下：

create table rb_build_test(a int[]);insert into rb_build_test values ('{1,2,3}');SELECT rb_build(a) FROM rb_build_test--报错信息HGERR_code XX000 HGERR_msge internal error: Not support calling pg udf for type (23, LIST)

直接执行rb_build函数不带表名则运行成功，示例SQL如下：

SELECT rb_build('{1,2,3}')--返回结果rb_build\x3a300000010000000000020010000000010002000300

执行rb_build函数带有表名时，会先计算然后落表，该函数执行是在HQE中，而当前版本HQE暂时不支持数组和PQE数组的双向转换，所以执行失败。

出现版本：

V1.3.37及以下版本。

修复版本：

V1.3.38及以上版本。

建议升级到最新版本。

P2

SQL中包含limit x offset y语句，其中y>x，运行SQL后返回结果数错误。示例SQL如下，本应该返回2行结果，实际返回0行。

create table test (id int, msg text);insert into test values (1, 'a'), (2, 'b'), (3, 'c'), (4, 'd');SELECT * FROM (SELECT * FROM test order by id limit 2) x limit 4 offset 3;

在生成执行计划时，当offset值超过limit值的时候，仍然将limit下推给了算子，但offset没有下推，导致查询结果不正确。

出现版本：

V1.3.20至V1.3.36版本。

修复版本：

V1.3.37及以上版本。

  • 修改SQL，将SQL中 offset的值改为小于limit的值。

  • 建议升级到最新版本。

P2

执行ANALYZE操作时报错：ERROR: store statistic results for table `public.table_name` failed: basic_string::_M_create。

ANALYZE在解析表的字段时未处理正确，导致报错。

出现版本：

V1.3.36版本。

修复版本：

V1.3.37及以上版本。

建议升级到最新版本。

P2

指定schema（非public schema）时执行create table as命令，报错找不到表，示例SQL如下：

create schema test_schema;set search_path to test_schema;create table test_src (a int);insert into test_src values (1);create table as test_src_1 SELECT * FROM test_src--报错信息error:relation "xxx" does not exist;

使用set search_path to 命令指定特定Schema后，create table as语法中表名称未添加Schema前缀的情况下，系统还是会默认从public Schema下搜索源表、插入数据，但public Schema下没有此表，导致报错。

出现版本：

V1.3.20至V1.3.36版本。

修复版本：

V1.3.37及以上版本。

  • create table as语法中为表指定schema，示例：

    create table as test_schema.test_src_1 SELECT * FROM test_src;

  • 建议升级到新版本。

P2

设置bigserial类型字段的起始值超过int4范围（-2147483648 ~ 2147483647），查询表数据时起始值不正确，示例SQL如下：

create table if not exist test_tb(  id bigserial not null,  f1 text,  primary key (id,f1));--在insert语句中，给f1字段插入数据。insert into test_tb(f1) values('1'),('2'),('3');-- 修改自增起始值100000000000alter sequence public.test_tb_id_seq restart with 100000000000-- 插入两条数据测试insert into test_tb(f1) values('6'),('7');SELECT * FROM test_tb order by id asc;--返回结果id| f1------------+----1 | 12 | 23 | 31128270048 | 61128270049 | 7

当前版本对bigserial类型起始值支持的数据范围是int4的范围（-2147483648 ~ 2147483647）。当设置的起始值超过支持的范围后，会出现精度溢出，从而导致结果不正确。

出现版本：

V1.3.20至V1.3.35版本。

修复版本：

V1.3.36及以上版本。

建议升级到新版本。

P2

Hologres实例从V1.1版本升级到V1.3版本后，查询、写入分区表Array类型时报错：internal error: Datasets has different schema Schema，且SQL命中的分区有升级前的分区和升级后创建的分区。

分区表父表的Array类型的字段未指定not null属性，当前版本处理Array的nullable属性处理有误，升级前默认为nullable，升级后新创建子表默认为not null，当查询同时命中升级前后多个分区时，由于分区子表元数据不一致，导致执行报错。

出现版本：

V1.3.20至V1.3.35版本。

修复版本：

V1.3.36及以上版本。

  • 对分区父表执行一次修改表属性操作，示例：

    call set_table_property('table_name', 'time_to_live_in_seconds', 'xx');

  • 建议升级到新版本。

2023年01月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

分区表场景下，开启JSONB列存，查询分区父表时速度慢，但查询子表速度很快。示例SQL如下：

CREATE TABLE public.hologres_parent(a text, b jsonb) PARTITION BY LIST(a);CREATE TABLE public.hologres_child1 PARTITION OF public.hologres_parent FOR VALUES IN('v1');SELECT b->>'xxx' FROM hologres_parent;

开启JSONB列存后，查询分区父表，优化器无法将查询下推到分区子表，导致查询出整列JSONB，从而性能变差。

出现版本：

V1.3.20至V1.3.34版本。

修复版本：

V1.3.35及以上版本。

  • 直接查询分区子表。

  • 建议升级到最新版本。

P2

使用JSONB列存时，带LIMIT过滤，列存不生效，查询速度慢。

create table jsonb_test(inputvalues JSONB );SELECT inputvalues ->> 'price' pos_id FROM jsonb_test where inputvalues ->> 'price' = 'aaa' limit 100;

在有LIMIT的情况下，执行计划中列存下推失败，导致计算时会查询出整列JSONB，从而出现性能退化。

出现版本：

V1.3.20至V1.3.34版本。

修复版本：

V1.3.35及以上版本。

  • 开启JSONB列存后不加LIMIT。

  • 建议升级到最新版本。

P0

在开启MC外表直读场景下，实例因为某些原因重启（如扩容计算节点、OOM等）造成实例服务无法启动。

MC直读时在因为系统实现缺陷，存在一定概率造成元数据与数据状态不一致，造成存储引擎无法正常加载数据，造成启动失败。后续修正问题时，有可能存在丢失删除状态的问题。

出现版本：

V1.3.14至V1.3.33版本。

修复版本：

V1.3.34及以上版本。

  • 建议低版本不要开启MC直读功能。

  • 建议升级到新版本。

P2

查列存表Binlog，且设置了Segment Key，WHERE过滤条件为Segment Key，查询时，过滤条件无效。示例SQL如下：

BEGIN;CREATE TABLE test (  id int PRIMARY KEY,  title text NOT NULL,  c_time timestamptz);CALL set_table_property ('test', 'orientation', 'column');call set_table_property('test', 'event_time_column', 'c_time');call set_table_property('test', 'binlog.level', 'replica');call set_table_property('test', 'binlog.ttl', '86400');COMMIT;SELECT hg_binlog_lsn,hg_binlog_event_type,hg_binlog_timestamp_us,* FROM test where c_time = 1;

示例中，查询结果中c_time不等于1，为其他值。

列存表设置了Binlog和Segment Key，在WHERE条件中使用Segment Key过滤，生成了错误的执行计划，导致过滤无效。

出现版本：

V1.3.33及以下版本。

修复版本：

V1.3.34及以上版本。

建议升级到新版本。

P2

使用#>操作符解析JSONB时报错：Unicode escape values cannot be used for code point values above 007F when the server encoding is not UTF8.示例建表SQL如下：

create table t1 (f1 json);insert into t1 values ('{"a":"Hello\u00F7"}');SELECT f1 #> ARRAY['a'] FROM t1;

#>操作符实际上是通过json_extract_path函数去解析，解析JSONB类型时，默认使用Postgres的ASCII码，导致报错。

出现版本：

V1.3.33及以下版本。

修复版本：

V1.3.34及以上版本。

建议升级到新版本。

2022年历史缺陷

2022年12月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

创建一个新的数据库，权限模型设置为SPM后，第一次使用JDBC消费Hologres Binlog出现报错：ERROR: internal error: create table hologres.hg_replication_progress failed。

在JDBC消费Hologres Binlog时为了让所有用户看到hg_replication_progress，系统会发出GRANT SELECT ON TABLE hologres.hg_replication_progress TO PUBLIC;的授权命令，但是SPM禁用GRANT命令，导致创建失败，从而消费Binlog报错。

出现版本：

V1.3.20至V1.3.32版本。

修复版本：

V1.3.33及以上版本。

  • 先切换至专家权限模型授权再使用SPM模型消费Binlog或者直接使用专家权限模型消费Binlog。

  • 建议升级到新版本。

P1

Hologres实例升级到V1.3.30版本后，内存使用率不明原因上涨，业务QPS、数据量等均没有变化。

在Hologres中默认会有Result Cache，在Result Cache插入失败时资源没有及时析构，从而出现内存使用率上涨。

出现版本：

V1.3.30至V1.3.31版本。

修复版本：

V1.3.32及以上版本。

建议升级到新版本。

P2

jsonb_object_filed嵌套jsonb_array_element时报错：internal error: Only jsonb_object_field and jsonb_object_field_text supported，示例SQL如下。 

create table t1(f1 jsonb);insert into t1 values ('[{"a":1},{"b":2}]');SELECT  f1->0->'a' FROM t1;

函数嵌套逻辑错误，导致值不匹配。

出现版本：

V1.3.20至V1.3.29版本。

修复版本：

V1.3.30及以上版本。

建议升级到新版本。

P2

查询只读从实例中的表时出现主键重复，查询主实例中相同的表则没有主键重复。

数据刚导入时就执行删除，且只读从实例刚好因为升级、扩容等原因Failover，导致从实例中重复的主键数据没有及时清理掉，从而出现从实例主键数据重复。

出现版本：

V1.3.27至V1.3.28版本。

修复版本：

V1.3.29及以上版本。

  • 使用主实例提供查询。

  • 建议升级到新版本。

2022年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

建表时，nullable的字段设置为Clustering Key或Segment Key ，查询数据时有偶发结果不一致的现象。

含有nullable Clustering Key或Segment Key的表，查询的时候，Result Cache中的结果缓存错误，导致查询结果不一致。

出现版本：

V1.1.30至V1.3.27版本。

修复版本：

V1.3.28及以上版本。

  • 重新建表并指定设置Clustering Key或Segment Key的字段不能为空。

  • 建议升级到新版本。

P2

使用ST_Collect(col)函数时报错：ERPC_CONNECTION _CLOSED。

PostGIS函数兼容PostgreSQL，Hologres中使用原生PostgreSQL的node tag值进行判断，判断错误导致报错。

出现版本：

V1.3.27及以下版本。

修复版本：

V1.3.28及以上版本。

建议升级到新版本。

P2

使用string_agg(text)函数出现报错：An I/O error occurred while sending to the backend 。

string_agg函数在Hologres中是走PQE，当string_agg(text)没有指定分隔符时，PQE处理该函数出现空指针，导致查询报错。

出现版本：

V1.3.20至V1.3.27版本。

修复版本：

V1.3.28及以上版本。

  • 修改SQL，为string_agg(text,',')显式指定分隔符。

  • 建议升级到新版本。

P2

读取MaxCompute外部表数据时，使用WITH语句，查询结果与不带WITH语句的结果不一致。

在读取CFile、RANGE TABLE等格式的MaxCompute外部表时，同时命令语句中含有WITH子句且WITH子句输出的列顺序与表中列顺序不一致，Hologres外部表接口输出的结果顺序错误，导致查询结果不一致。

出现版本：

V1.3.24至V1.3.26版本。

修复版本：

V1.3.27及以上版本。

  • 不使用WITH语句进行查询。

  • 建议升级到新版本。

P2

查询MaxCompute外部表ARRAY类型的字段报错：Array length did not match record batch length。

访问MaxCompute ORC格式的表时，Hologres外部表对于ARRAY类型的字段接口长度处理不一致，导致ARRAY数据长度超过限制，出现报错。

出现版本：

V1.3.20至V1.3.26版本。

修复版本：

V1.3.27及以上版本。

建议升级到新版本。

2022年10月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

将Distribution Key设置为空字符串时查询报错：Failed to get bh reader: internal error CONTEXT。示例DDL如下：

call set_table_property('<table_name>', 'distribution_key', ' ');

Distribution Key设置为空字符串时，无法正确路由到数据所在的Shard，导致查询报错。

出现版本：

V1.3.24及以下版本。

修复版本：

V1.3.26及以上版本。

  • 重新建表，并设置合理的Distribution Key。

  • 建议升级到新版本。

    说明

    升级后仍然不支持Distribution Key设置为空，建表时会报错。

P2

查询MaxCompute外部表时报错：column with id 0 has type date64[ms] but ReadColumn returns array Array(type=timestamp[ms, tz=UTC]。

Hologres读取MaxCompute外部表时，DATETIME类型转换错误，导致查询报错。

出现版本：

V1.3.20至V1.3.24版本。

修复版本：

V1.3.25及以上版本。

建议升级到新版本。

P2

Hologres实例升级 V1.3.20版本后，查询带有数组类型字段的MaxCompute外部表时报错：internal error: IOError: Invalid flatbuffers message。

读取MaxCompute外部表时，因读取接口版本较低，无法识别数组类型，导致查询报错。

出现版本：

V1.3.20至V1.3.24版本。

修复版本：

V1.3.25及以上版本。

  • 暂时避免查询数组类型的字段。

  • 建议升级到新版本。

P2

PostgreSQL系统表导入至Hologres表，Hologres表结果随机变化，不稳定。示例如下：

-- 查询结果 22505SELECTcount(1)FROMpg_class c inner join pg_attribute a on c.oid = a.attrelid-- 创建内部表CREATE TABLE public. tables11 (schemaname name NULL);truncate public. tables11-- 插入数据随机变换insert into public.tables11SELECT'tmp'FROMpg_class c inner join pg_attribute a on c.oid = a.attrelidSELECT count(1) FROM public.tables11

PostgreSQL系统表为PostgreSQL原生系统表，Hologres是分布式系统，每个FE节点因为不断执行DDL导致节点的版本不一致。查PostgreSQL系统表时，从不同的节点获取数据，导致结果不稳定。

出现版本：

V1.3.22至V1.3.24版本。

修复版本：

V1.3.25及以上版本。

建议升级到新版本。

P2

Hologres实例升级至V1.3.20及以上版本后，case when语句中含有DECIMAL类型字段的查询报错：internal error: column with id 0 has type decimal(38, 3) but ReadColumn returns array Array(type=decimal(38, 10) length=3 null_count=0。

在case when语句中，DECIMAL未被显示转换精度，优化器（QO）在推导执行计划时，精度推导错误，从而导致执行报错。

出现版本：

V1.3.20至V1.3.24版本。

修复版本：

V1.3.24及以上版本。

建议升级到新版本。

P2

PostgreSQL系统视图导入到业务创建的Hologres表中，Hologres表中没有数据，示例SQL如下。

CREATE table holo_pg_tables (schemaname text,tablename text,tableowner text,tablespace text,hasindexes text,hasrules text,hastriggers text,rowsecurity text);insert into holo_pg_tables SELECT * FROM pg_catalog.pg_tables;

Postgresql系统视图pg_catalog.pg_tables中有个过滤条件：c.relkind = ANY (ARRAY['r'::"char", 'p'::"char"])，此类型在转执行计划的时候被错误转成某个无意义的数值，导致没有数据命中。

出现版本：

V1.3.22至V1.3.24版本。

修复版本：

V1.3.25及以上版本。

建议升级到新版本。

P2

使用Proxima向量查询时，为表设置了两个Proxima向量索引，查询时性能较设置一个索引时更差，设置索引的DDL示例如下。

call set_table_property('t1', 'proxima_vectors', '{"f2":{"algorithm":"Graph","distance_method":"InnerProduct"}},{"f3":{"algorithm":"Graph","distance_method":"InnerProduct"}}');

设置两个索引时，DDL中{}书写错误，应该一个索引对应一个{}。FE侧未正确拦截该格式的DDL，导致第一个索引构建成功，第二个索引被丢弃，从而导致查询性能下降，正确的书写格式如下：

call set_table_property('t1', 'proxima_vectors', '{"f2":{"algorithm":"Graph","distance_method":"InnerProduct"},"f3":{"algorithm":"Graph","distance_method":"InnerProduct"}}');

出现版本：

V1.3.24及以下版本。

修复版本：

V1.3.25及以上版本。

  • 重新建表并将设置索引DDL改为正确的书写格式。

  • 建议升级到新版本。

    说明

    升级最新版本后，仍然不支持该错误的书写，但是建表时会报错。

P2

非Superuser用户执行SELECT hg_dump_script('xxxx')命令时报错：ERROR: permission denied for table pg_subscription。

hg_dump_script函数间接调用pg_subscription进行逻辑复制，pg_subscription鉴权失败导致出现报错。

出现版本：

V1.3.20至V1.3.24版本。

修复版本：

V1.3.25及以上版本。

  • 使用Superuser账号进行授权，命令示例如下。

    grant SELECT on pg_subscription to "xx";

  • 建议升级到新版本。

P2

使用RAM用户通过Flink消费Hologres Binlog或者通过DataHub写入数据至Hologres时，报错：NoSuchProject。

接入节点（Frontend）对RAM用户解析错误，导致报错。

出现版本：

V1.3.23及以下版本。

修复版本：

V1.3.24及以上版本。

建议升级到新版本。

P2

Hologres实例从 V1.1版本升级至 V1.3版本后，MaxCompute外部表查询耗时增加，通过查看执行计划（explain sql）发现，表统计信息的row_count为1000，即统计信息未自动更新。

Hologres实例升级到 V1.3版本后，Auto Analyze未检测到外部表的Schema，导致未能及时获取到外部表的统计信息。

出现版本：

V1.3.14至V1.3.23版本。

修复版本：

V1.3.24及以上版本。

  • 手动执行analyze <tablename>命令。

  • 建议升级到新版本。

P2

查询语句中的union all含有DECIMAL类型字段时报错：Schema fields[4] has type decimal(14, 4) but decimal(11, 2) is expected。

示例如下：

create table t1(n decimal(6,4));create table t2(n decimal(5,3));SELECT * FROM (SELECT 1 as type, n FROM t1 union all SELECT 2 as type, n FROM t2)t where t.type=2;

使用union all在生成执行计划时，对DECIMAL类型的精度进行了额外裁剪，导致结果精度错误。

出现版本：

V1.3.20至V1.3.23版本。

修复版本：

V1.3.24及以上版本。

建议升级到新版本。

2022年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

JDBC连接串指定了Schema，但是Schema没有生效，仍然为public Schema。连接示例如下：

String jdbcUrl = "jdbc:postgresql://hostname: port /dbname?currentSchema=demo;

FE节点对于连接串中?后的字符串未处理，导致currentSchema设置未生效。

出现版本：

V1.3.14至V1.3.22版本。

修复版本：

V1.3.23及以上版本。

建议升级到新版本。

P1

创建了物化视图，SQL查询命中物化视图自动改写，导致实例出现短暂重启。

命中物化视图自动改写的SQL，优化器在生成执行计划时获取表的Meta数据失败，导致实例异常。

出现版本：

V1.3.14至V1.3.22版本。

修复版本：

V1.3.23及以上版本。

建议升级到新版本。

P2

在一个实例内为不同用户设置不同的IP白名单策略，这些用户在白名单的IP内无法访问Hologres实例，报错：reject ip xxx。

为用户设置IP白名单后，网关拦截了用户，导致实际上用户并没有被设置在白名单内。

出现版本：

V1.3.21及以下版本。

修复版本：

V1.3.22及以上版本。

  • 不设置IP白名单，或者将白名单的用户策略改为ALL（即将数据库限制参数设置为ALL）。

  • 建议升级到新版本。

P2

Fixed Plan的点查场景下查询 Decimal类型数据报错：get result failed: scale should between xxxx。示例如下：

begin;create table t (k1 int, k2 decimal(18, 2), primary key(k1, k2));call set_table_property ('t', 'distribution_key', 'k1');end;insert into t (1, 12.11);set hg_experimental_enable_fixed_dispatcher_for_scan = on;SELECT * FROM t where k1=1 and k2>10.1 and k2 < 12.3;

Fixed Plan场景下Deciaml类型精度推导错误，导致结果报错。

出现版本：

V1.3.20及以下版本。

修复版本：

V1.3.21及以上版本。

建议升级到新版本。

P2

开启IP白名单之后，Flink消费Hologres Binlog报错：reject ip 1.xxx。

Flink消费Hologres binlog使用的接口为Hologres实时数据导入接口（非JDBC模式），该接口暂不支持开启IP白名单功能。

出现版本：

V1.3.20及以下版本。

修复版本：

V1.3.21及以上版本。

  • 不设置IP白名单。

  • 建议升级到新版本。

P2

将数组类型显式转换成String类型时，报错：ERROR: Cast FROM LIST to STRING is not supported.。示例如下：

create table aaa1(a text[],b int[]);insert into aaa1 values (ARRAY['1','aaa'], ARRAY[1,2,3]);d=# SELECT a::text, b::text FROM aaa1;

当前Hologres暂不支持将数组类型显式转换成String类型。

出现版本：

V1.3.20及以下版本。

修复版本：

V1.3.21及以上版本。

建议升级到新版本。

P1

在查询MC外表时，查询卡住，在重启实例后，卡住现象消失。

在Hologres读取MC元数据时， 如果MC元数据服务发生主备切换，Hologres没有能够正确处理异常场景，造成重试失败，引起查询卡顿。

出现版本：

V1.3.20及以下版本。

修复版本：

V1.3.21及以上版本。

建议升级到新版本。

2022年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

使用JDBC Prepare Statement模式执行SQL查询时报错：cannot push query id when transaction is not start。

在JDBC Prepare Statement模式下，执行SQL实际上还没有开始事务，导致无法生成Query ID，从而报错。

出现版本：

V1.1.80至V1.1.86版本。

修复版本：

V1.3.20及以上版本。

  • JDBC连接串修改为Simple模式：jdbc:postgresql://<host>:<port>/<dbname>?preferQueryMode=simple。

  • 建议升级到新版本。

P2

修改TTL时，设置的TTL值中间带了逗号（,）：CALL set_table_property('wdt_qyb.wdt_qyb_trade', 'time_to_live_in_seconds', '315,360,000');导致数据很快被删除。

带逗号的TTL值315,360,000属于非法数值，在解析SQL时会默认将逗号后的值去掉，导致TTL被设置成了315s，数据因为过期被清理。

出现版本：

V1.1.85及以下版本。

修复版本：

V1.3.20及以上版本。

  • 设置TTL时使用INT类型且不使用逗号。

  • 建议升级到新版本。

    说明

    升级后，带逗号的非法TTL值在建表、修改TTL时，将会报错。

P2

行存表Clustering Key和PK设置不一致时，查询报错：internal error: Cannot build column col1。

示例如下：

CREATE TABLE test(col1 text,col2 text,col3 text,PRIMARY KEY (col1, col2)); CALL set_table_property('public.test', 'distribution_key', 'col1'); CALL set_table_property('public.test', 'clustering_key', 'col1:asc');SELECT * FROM public.test;

当行存表Clustering Key和PK设置不一致时，存储引擎会错误地生成相同的Record，导致查询报错。

出现版本：

V1.1.84及以下版本。

修复版本：

V1.3.20及以上版本。

  • 行存表设置相同的Clustering Key和PK。

  • 建议升级到新版本。

P2

非Superuser账号通过JDBC消费Hologres Binlog时，执行call hg_create_logical_replication_slot('hg_replication_slot_1', 'hgoutput', 'hg_publication_test_1');命令时报错：permission denied for table hg_replication_slot_properties。

JDBC消费Hologres Binlog时需要使用Superuser账号，否则会没有权限。

出现版本：

V1.1.83及以下版本。

修复版本：

V1.3.20及以上版本。

P2

查询慢Query日志时缺少日志，但是监控信息上却显示延迟和QPS。

同一事务（Transaction）中不同Query有相同Query ID，元仓收集Query去重后只保留了一条Query，导致其他Query丢失。

出现版本：

V1.1.80及以下版本。

修复版本：

V1.3.20及以上版本。

建议升级到新版本。

P2

消费Hologres Binlog时报错：com.alibaba.hologres.org.postgresql.util.PSQLException: ERROR: relation "hologres.hg_replication_slot_properties" does not exist。

实例因某个原因有过FE节点重启，节点恢复后没有将Hologres Binlog的Extension恢复，导致消费失败。

出现版本：

V1.3以下版本。

修复版本：

V1.3.20及以上版本。

建议升级到新版本。

2022年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

热升级之后查询表报错：File(fn: xxx) real size != size in meta: 0 != yyyy。

实例进行热升级，热升级过程中表有离线BulkLoad写入，离线写入时数据会进行Compaction，导致元数据存在兼容性问题从而出现报错。

出现版本：

V1.1.80及以下版本。

修复版本：

V1.1.81及以上版本。

  • 实例热升级时暂停表的离线写入或者使用普通冷升级。

  • 建议升级到新版本。

P2

同时回写MaxCompute同一表的不同分区时报错：ERROR:commit uploder failedErrorMessage=Operation failed due to concurrent upload/insert operationson the same table。

不同的MaxCompute分区属于同一个表，在回写时，回写接口执行commit upload session时会共享同一个表锁，导致锁冲突报错。

出现版本：

V1.1.78及以下版本。

修复版本：

V1.1.79及以上版本。

建议升级到新版本。

2022年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

Analyze OSS外部表时，出现OOM（Out Of Memory）。

在对OSS外部表执行Analyze时，OSS行数获取接口会默认采样的行数较大（超过3万行），从而出现OOM。

出现版本：

V1.1.76及以下版本。

修复版本：

V1.1.77及以上版本。

建议升级到新版本。

P2

含有in查询的SQL，当in中常量类型和列的实际类型不一致时，报错：internal error: Invalid filter value type int32 for column type int16。

示例SQL如下。

create table test(pid smallint);insert into test values (1);SELECT pid FROM test where pid not in (4, 5);

in算子指定的常量数据类型和原列类型不同时，优化器（QO）没有对常量进行cast类型转换，导致在执行器（QE）端报错。

出现版本：

V1.1.73及以下版本。

修复版本：

V1.1.74及以上版本。

  • in中的常量类型和列的类型保持一致。

  • 建议升级到新版本。

P2

创建OSS外部表时，只选择部分字段创建外部表，创建时报错：Open ORC file failed for schema mismatch。

选择部分OSS字段创建外部表时，引擎对部分外部表的支持有限制，只能选择全部字段。

出现版本：

V1.1.73及以下版本。

修复版本：

V1.1.74及以上版本。

  • 选择全部字段创建外部表。

  • 建议升级到新版本。

P2

删除某一段区间的数据之后（如删除某个分区），立即对同一张表执行insert命令，写入的速度变慢。

当删除了一个区间或者一段连续的值之后，此时Compaction还未全部完成，执行insert命令时，会先去查询该时间段是否有相同的记录，直到遇到第一条没被删除的记录才能停下来，如果查询的Key附近有大量连续删除的记录，会消耗很多时间在遍历这些记录上，导致insert命令写入速度慢。

出现版本：

V1.1.70及以下版本。

修复版本：

V1.1.71及以上版本。

建议升级到新版本。

2022年05月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

查MaxCompute表报错：Timestamp overflow detected while converting timestampFROM orc VectorBatch to arrow。

在MaxCompute表中有TIMESTAMP类型，使用Tunnel写入后TIMESTAMP精度会变成纳秒，目前Hologres暂不支持精度为纳秒的TIMESTAMP，导致报错。

出现版本：

V1.1.69及以下版本。

修复版本：

V1.1.70及以上版本。

  • 修改MaxCompute表的TIMESTAMP类型为DATETIME类型。

  • 建议升级到新版本。

P2

查询OSS Parquet数据时，通过count语句每次查出的结果不一致，而OSS数据没发生过变化。

Hologres读OSS Parquet文件时，接口版本较老，导致读取非Null数据中会随机出现Null值，从而查询结果错误。

出现版本：

V1.1.67及以下版本。

修复版本：

V1.1.68及以上版本。

建议升级到新版本。

P2

在Hologres中使用SQL方式将数据回写MaxCompute时报错：Blocks not match, server:xx client yy。

在回写MaxCompute时，超时时间默认为300s，导致产生了空的Block，从而出现报错。

出现版本：

V1.1.64及以下版本。

修复版本：

V1.1.65及以上版本。

  • 通过执行如下命令修改超时时间。

    alter server odps_server options (add socket_timeout '600');

    修改超时时间为600s，不容易产生空Block。

  • 建议升级到新版本。

P2

Hologres V1.1版本在对MaxCompute外部表增加多列时报错：not support alter table with multi commands。示例SQL如下。

ALTER FOREIGN TABLE bank ADD COLUMN cons_conf_idx float8, ADD COLUMN euribor3m float8;

Hologres V1.1版本增加了对外部表add column状态的检查，当增加多列时，状态检查错误，导致增加列失败。

出现版本：

V1.1.1至V1.1.58版本。

修复版本：

V1.1.59及以上版本。

  • 一次只新增一个列或者使用IMPORT FOREIGN SCHEMA语法刷新外部表。

  • 建议升级到新版本。

P1

使用to_date函数带where过滤条件查询时报错：invalid value \"\" for \"YYYY\" HGERR_detl Field requires 4 characters, but only 0 could be parsed。示例查询SQL如下。

SELECT *  FROM public.test where to_date(content, 'YYYYMMDD' ) BETWEEN  '2021-10-22' AND '2021-10-23' limit 10;

使用to_date函数带where过滤条件时，where过滤的数据被识别为了非法数据进行转换，导致报错。

出现版本：

V1.1.58及以下版本。

修复版本：

V1.1.59及以上版本。

建议升级到新版本。

P2

并发读取MaxCompute加密的表时，出现报错：failed to load row group data FROM file pangu。

在并发读取MaxCompute加密表时，Reader并发解析加密对象，导致解密错误。

出现版本：

V1.1.57及以下版本。

修复版本：

V1.1.58及以上版本。

建议升级到新版本。

P2

对NUMERIC或者DECIMAL类型的字段执行求余（%）计算，且下推至HQE中执行，导致计算结果不正确。

HQE不支持NUMERIC和DECIMAL类型的求余，但未做类型校验，导致结果出错。

出现版本：

V1.1.55及以下版本。

修复版本：

V1.1.56及以上版本。

  • 不对NUMERIC和DECIMAL类型的字段执行求余计算。

  • 建议升级到新版本。

    说明

    升级后仍然不支持对NUMERIC和DECIMAL类型的字段执行求余计算，会直接报错。

2022年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

通过JDBC订阅Hologres Binlog，启动JDBC消费Binlog作业pgreplicationstream.start()在数据库端同时执行drop table xx;删除对应表，导致实例出现短暂重启。

订阅Binlog时删除表，会导致订阅时表不存在，但是订阅Binlog需要获取表的table_properties，导致空指针，出现实例重启现象。

出现版本：

V1.1.54及以下版本。

修复版本：

V1.1.55及以上版本。

  • 订阅Hologres Binlog时不删除表。

  • 建议升级到新版本。

    说明

    升级Hologres实例后若是订阅Binlog时删除表，会报表不存在。

P2

分区子表执行detach父表之后，再attach至同一个父表上，无法attach。

通过CREATE TABLE <table_name> PARTITION OF <parent_table>命令创建的分区子表，不会继承父表的Table Group属性，当分区子表detach后再进行attach时，校验出子表与父表的Table Group属性不一致，导致无法进行attach。

出现版本：

V1.1.52及以下版本。

修复版本：

V1.1.53及以上版本。

建议升级到新版本。

P2

当使用Grouping sets和多个Count Distinct对分区表进行查询时，查询结果不正确。

Grouping sets和多个Count Distinct对分区表查询时，优化器未对分区进行裁剪，导致分区过滤条件未命中，从而出现结果不正确。

出现版本：

V1.1.52及以下版本。

修复版本：

V1.1.53及以上版本。

建议升级到新版本。

2022年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

通过DLF查询OSS外部表时报错：failed to import foreign schema ，创建user-mapping后能正常查询。

没有设置user-mapping时，鉴权接口传递权限错误，导致查询报错。

出现版本：

V1.1.50及以下版本。

修复版本：

V1.1.51及以上版本。

  • 显式设置user-mapping，详情请参见基于DLF访问OSS数据湖加速。

  • 建议升级到新版本。

    说明

    升级到新版本后不需要显示创建user-mapping即可正常访问相关数据。

P2

PrepareStatement模式下查询SQL报错：unrecognized node type: 0或者Hologres实例出现短暂重启。

PrepareStatement模式下可以对反复执行的SQL生成Plan cache，减少接入端的开销。而在当前版本PrepareStatement模式对SQL的Plan cache获取不及时，导致查询出错。

出现版本：

V1.1.47至V1.1.50版本。

修复版本：

V1.1.51及以上版本。

  • 使用jdbc:postgresql://<host>:<port>/<dbname>?preferQueryMode=simple命令将JDBC连接串修改为Simple模式。

  • 建议升级到新版本。

P1

Blink或者Flink RPC模式写入Hologres时报错：failed to create channel into server xxx，connection refused to rpc proxy endpoint。

使用Blink或者Flink RPC模式写入Hologres时，接口未返回Rpcproxy端口，导致写入报错。

出现版本：

V1.1.50及以下版本。

修复版本：

V1.1.51及以上版本。

  • 将Flink作业切换为JDBC写入模式，详情请参见Flink全托管。

  • 建议升级到新版本。

P2

执行含有union all的Join SQL命令时报错：internal error: 0 shard end shard value: xxx doesn\'t 。

含union all的JOIN SQL在推导执行计划时错误，导致报错。

出现版本：

V1.1.49及以下版本。

修复版本：

V1.1.50及以上版本。

建议升级到新版本。

P2

使用json_array_elements函数且SQL中含有Join命令时，报错：Duplicate keys detected when building hash table。

执行引擎（QE）在执行Join算子时会构建哈希表，但是实际读数据时，没有正常过滤json_array_elements处理后的数据，导致读取的数据有重复从而报错。

出现版本：

V1.1.49及以下版本。

修复版本：

V1.1.50及以上版本。

建议升级到新版本。

P2

执行Join SQL时报错：Explicit remote seek FROM a source is not supported。

Join SQL生成的执行计划（通过explain sql查看）是Nested Loop Join时，执行引擎获取Nested Loop Join相关的执行计划错误，导致执行报错。

出现版本：

V1.1.49及以下版本。

修复版本：

V1.1.50及以上版本。

建议升级到新版本。

P2

SQL过滤条件中含有not in时，查询结果中仍然含有not in过滤的数据。示例如下。

create table if not exists test(id bigint,  value int);SELECT id FROM test where id in (238024008,276941010) and id not in (238024008) and value in (1, 2, 3);

优化器在生成执行计划时，对not in处理错误，生成了错误的执行计划，导致not in过滤条件丢失，结果出错。

出现版本：

V1.1.48及以下版本。

修复版本：

V1.1.49及以上版本。

建议升级到新版本。

P2

SLPM权限模型下，修改Schema名称时执行CALL slpm_rename_schema ( old_name, new_name )命令，报错：UPDATE is not supported。

SLPM权限模型下修改Schema时，权限接口判断错误，导致执行报错。

出现版本：

V1.1.47及以下版本。

修复版本：

V1.1.48及以上版本。

建议升级到新版本。

2022年02月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

SPM或者SLPM模式下，开启数据脱敏后，进行Auto Analyze或者Analyze失败。

后端会使用表Owner去执行Auto Analyze，但SPM或者SLPM模式下，表的Owner是Developer，没有登录权限，而对脱敏列采样时会走PQE，导致Auto Analyze或者Analyze失败。

出现版本：

V1.1.1至V1.1.46版本。

修复版本：

V1.1.47及以上版本。

  • 关闭数据脱敏。

  • 建议升级到新版本。

P1

Analyze外部表时，外部表分区太多（通常是多级分区场景）报错超过分区限制（大于512分区），导致Analyze失败。

Analyze时未对外部表分区进行相应裁剪，导致Analyze失败。

出现版本：

V1.1.1至V1.1.46版本。

修复版本：

V1.1.47及以上版本。

  • 若是外部表分区数在1024以内，可以先将外表分区限制调大再执行Analyze。

  • 建议升级到新版本。

    说明

    升级后默认Analyze 最多512个外部表分区，若是需要更多分区，请将Analyze分区限制数调大，详情请参见优化MaxCompute外部表的查询性能。

P1

执行explain analyze SQL命令时，结果中partitions SELECTed 为0，与实际命中分区不符。

生成执行计划时对partitions SELECTed 判断错误，导致结果为0。

出现版本：

V1.1.1至V1.1.46版本。

修复版本：

V1.1.47及以上版本。

建议升级到新版本。

P2

查看慢Query日志时，无法显示查询读取的行数（read_rows）、返回行数（result_rows）等信息。

元仓采集信息不全导致。

出现版本：

V1.1.1至V1.1.46版本。

修复版本：

V1.1.47及以上版本。

建议升级到新版本。

说明

Hologres V1.1.36版本开始可以通过GUC参数查看，V1.1.47版本后可以不使用GUC参数。

P2

使用JDBC PrepareStatement模式时，insert或者SELECT多个值时，多执行几次（大于3次）结果出现错行错列，而一次insert或者SELECT一个值分多次执行时结果正确。示例如下：一条SQL包含32个values一次写入，总共写4次，每次这32行数据在values中的顺序随机变化。而一条SQL只包含一个values，分32条sql写入，结果正确。

PrepareStatement模式下对多个values进行多次insert或者SELECT时，优化器（QO）生成了错误的执行计划，导致结果出错。

出现版本：

V1.1.46及以下版本。

修复版本：

V1.1.47及以上版本。

  • Query符合Fixed Plan特征时，可以开启Fixed Plan加速SQL执行。

  • 将PrepareStatement模式更改为Simple模式。

  • 建议升级到新版本。

P2

执行非Join的SQL（例如含有count distinct）时，报错：error: Hash32 shard function does not support decimal or fixed binary type。

非Join的SQL也可能会使用Shard Function生成执行计划，而目前Shard Function不支持NUMERIC等类型，导致部分非精确类型在执行时报错。

出现版本：

V1.1.46及以下版本。

修复版本：

V1.1.47及以上版本。

建议升级到新版本。

P1

在使用key = max(key)时，出现的结果不符合预期，一直只出现一行数据，使用key in max(key)时符合预期。

优化器在生成执行计划时，会将key = max(key)，转化成order by id asc limit 1 ， 这种查询永远只有一行数据，导致结果不符合预期。

出现版本：

V1.1.46及以下版本。

修复版本：

V1.1.47及以上版本。

  • 使用key in max(key)。

  • 建议升级到新版本。

P2

非PostgreSQL来源（如JDBC）的DDL有SQL代码注释，示例：create table ttxwsx1(i int); -- comments -- xxxxx执行成功后，写入或者查询时出现卡死的现象。

DDL命令末尾有注释，会使得同一行最后的分号失去命令间的分隔作用，导致新生成的命令追加到注释后面失效，从而使得SQL不合法，导致节点间Replay失败，造成写入或者查询卡死。

出现版本：

V1.1.45及以下版本。

修复版本：

V1.1.46及以上版本。

  • 删除DDL语句最后的注释。

  • 建议升级到新版本。

P1

按照主键点查方式查询行存表时，存在一定概率场景，出现部分行存数据查询不到的情况。

行存表在做后台文件compaction时，在处理并发场景有缺陷，致使部分索引文件定位有误，导致部分行存数据查询不到。

出现版本：

V1.1.44及以下版本。

修复版本：

V1.1.45及以上版本。

建议升级到新版本

P2

Hologres实例升级至 V1.1版本后，查询MaxCompute外部表，当外部表有多级分区时（一般3级分区），SQL过滤条件中带有or，查询相比V0.10版本变慢（之前查询只需要几秒钟）或者出现OOM。

Hologres V1.1版本，在多级分区过滤中，优化器对or条件生成的算子无法识别，导致生成的filter为空，即不做任何过滤，从而扫描了所有分区，导致查询变慢或者出现OOM。

出现版本：

V1.1.44及以下版本。

修复版本：

V1.1.45及以上版本。

建议升级到新版本

P1

CPU占用不高时内存也长期处于高水位，通过监控发现QPS比较高（几百及以上），但是连接数只用了几十个，即一个Connection保持几百个QPS的速度执行SQL。

当执行SQL时，优化器会去获取表的statistics，当一个Connection保持几百个QPS的速度执行SQL，且Connection长期不关闭，导致获取statistics时泄漏，造成内存高水位。

出现版本：

V1.1.44及以下版本。

修复版本：

V1.1.45及以上版本。

  • 通过添加set hg_experimental_always_show_execution_statistics=off;参数解决。

  • 建议升级到新版本。

P2

SQL中含有not like xxx%条件，但是查询结果中仍然出现not like过滤后的数据。

优化器在生成执行计划时，对like相关的函数预处理规则出错，进行了错误的改写，导致结果不正确。

出现版本：

V1.1.44及以下版本。

修复版本：

V1.1.45及以上版本。

  • 带like的SQL出错时可以通过添加hg_experimental_remove_redundant_cmp=off;参数解决。

  • 建议升级到新版本。

P1

STS账号登录时，报错：Cloud authentication failed，并且检查账号密码等都没有填写错误。

账号认证接口对STS账号的状态判断错误，导致报错。

出现版本：

V1.1.43至V1.1.44版本。

修复版本：

V1.1.45及以上版本。

建议升级到新版本

P0

在应用侧数据写入完成，但引擎侧数据写入进程崩溃，有概率存在数据丢失，用户查询时发现数据缺少。

正常流程是用户写数据，WAL（Write Ahead Log）落盘后才返回给上层调用，表示写入完成，保证数据持久化和一致性。但当落盘进程写入超时触发系统重试后，数据会首先写入内存缓存部分，并返回给上层调用，如果此时内存缓存进程崩溃后，会造成应用层返回成功，但实际数据存储层丢失的问题。

出现版本：

V0.8及以下版本。

修复版本：

V0.9及以上版本。

建议升级到新版本

P1

实例写入和查询数据时失败并报错：ERROR: Invoke StoreMasterClient failed:ERPC_ERROR_CONNECTION_CLOSED。

出现报错后，业务侧进行Query重试叠加后端接入节点（FE）重试，导致请求量太高，Store Master（元数据管理）处理不及时而报错。

出现版本：

V1.1.43及以下版本。

修复版本：

V1.1.44及以上版本。

  • 使用set optimizer_join_order=query命令，暂时绕过。

  • 建议升级到新版本。

P2

新增一列类型为DECIMAL且不指定精度的列，如alter table add column c0 decimal; Query执行成功，但是查询新加的列时出现报错：Schema fields[] has type decimal(x,y) but decimal(x1, y1) is expected.。

当前新增列不支持DECIMAL不指定精度，但是新增列（Add Column）时没有做精度校验，导致查询报错。修复后在新增列时会对精度校验，未指定精度会报错。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

  • 新增列时含有DECIMAL字段时需要指定精度。

  • 建议升级到新版本。

P0

当AccessKey被禁用后，仍然能使用被禁用的AccessKey访问Hologres实例。

AccessKey接口对于禁用的AccessKey状态调用错误，导致禁用的AccessKey被当成了正常的AccessKey使用。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

  • 取消账号的访问权限。

  • 建议升级到新版本。

P2

建表时有Default字段，使用copy命令语句时，实例出现重启。

copy功能不支持建表时带有Default值，导致实例OOM发生重启。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

建议升级到新版本。

P2

执行有外表关联的INNER JOIN查询语句时，报错找不到某一列，如：ERROR: column "id" does not exist，而SQL中并没有这一列。

优化器在生成执行计划时，对于等价表达式的推导不对，没有输出的列也作为了等价表达式的推导，导致报错。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

建议升级到新版本。

P1

使用行列共存的表，带有复杂的Nested Loop Join，出现实例重启后又快速恢复。

优化器在检测行列共存的表时，没有生成正确的执行计划，导致报错从而触发实例重启。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

  • 不使用行列共存的表

  • 建议升级到新版本。

P1

多表（如6个表）Join的复杂导入作业在手动取消后，CPU使用率仍然为100%，持续几个小时不结束，执行drop table时也卡住。

比较复杂的Query，执行计划包括Hash Join算子，涉及到的数据量很大，后端出现锁死，导致取消后仍然在后端运行中。

出现版本：

V1.1.42及以下版本。

修复版本：

V1.1.43及以上版本。

  • 重启实例。

  • 建议升级到新版本。

2022年01月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

数据通过DataHub写入Hologres分区表时，分区表未提前创建分区子表，Hologres实例重启。

DataHub写入Hologres分区表时，写入接口未做分区校验，引发实例Coredump。

出现版本：

V1.1.41及以下版本。

修复版本：

V1.1.42及以上版本。

  • 在Hologres中提前创建好分区子表再写入数据。

  • 建议升级到新版本。

    说明

    若是分区表，升级后仍然需要提前创建分区子表才能写入数据。

P2

分区子表通过attach到分区父表后，查分区表时报错：partition_table_missing。

分区子表的建表属性与分区父表不一致（比如not null约束、PK设置，Clustering Key设置等），在attach时没有对属性进行校验，导致查询报错。

出现版本：

V1.1.41及以下版本。

修复版本：

V1.1.42及以上版本。

  • 建分区子表时，子表的Schema和属性需要同attach的分区父表保持一致。

  • 建议升级到新版本。

P1

使用JDBC PreparedStatement模式时，SQL中的where命令中含有"<"或者">"过滤条件，执行后出现实例重启。

使用JDBC PreparedStatement模式时，where中的"<"或者">"过滤条件会在生成执行计划时，转换成INTERVAL，在转换时遇见空指针，导致SQL出错引发实例重启。

出现版本：

V1.1.0至V1.1.40及以下版本。

修复版本：

V1.1.41及以上版本。

建议升级到新版本。

P1

使用JDBC PreparedStatement模式时，IN条件超过100个时，有一定概率结果出错或者不符合预期。

当使用JDBC PreparedStatement模式时，IN条件超过100个时，生成执行计划时会错误地把IN条件删除，导致数据结果出错。

出现版本：

V1.1.0至V1.1.40及以下版本。

修复版本：

V1.1.41及以上版本。

建议升级到新版本。

P2

行列共存的表使用IN条件查询时报错：An I/O error occurred while sending to the backend.，使用行存表则不会报错。

当IN条件中的字段类型是TEXT时，并且该字段设置了Bitmap，导致行列共存的表生成了错误的执行计划，从而报错。

出现版本：

V1.1.0至V1.1.40及以下版本。

修复版本：

V1.1.41及以上版本。

  • 使用行存表。

  • 建议升级到新版本。

P2

执行SQL，where条件中有and连接in和=时报错：ERROR: serialized_error_msg is null。示例SQL：

SELECT * FROM public.conflict_1 where a in (1,31) and a=1;

后端在判断and两侧in和=的数据类型时判断错误（示例：假如是 a = 1 就是一个int类型， a in (1,2,3) 就是一个array 类型），导致执行失败。

出现版本：

V1.1.0至V1.1.40及以下版本。

修复版本：

V1.1.41及以上版本。

建议升级到新版本。

P2

修改分区子表的生命周期（TTL）后出现报错：Invoke StoreMasterClient failed:ERPC_ERROR_CONNECTION_CLOSED。

修改子表TTL时，元数据管理器Store Manager（SM）检验Schema变动时出错，导致SQL出现报错。

出现版本：

V1.1.0至V1.1.40及以下版本。

修复版本：

V1.1.41及以上版本。

  • 暂不修改子表TTL。

  • 建议升级到新版本。

P2

使用DROP语句删除表时报错：invalid table id，重试时报错：SE object lock failed 。

一个实例会有多个接入节点，执行SQL时，是先在一个节点执行，再去其他节点重放（reply），当某个节点因为版本等原因无法跟其他节点保持元数据信息一致时，会进行重试（retry）。当并发执行drop table时，会触发节点的主动，retry时没有释放表锁导致报错。

出现版本：

V1.1.39及以下版本。

修复版本：

V1.1.40及以上版本。

  • 串行执行drop table等DDL。

  • 建议升级到新版本。

P1

开启Auto Analyze功能之后，实例没有明显上涨的QPS，出现报错：database is not accepting commands to avoid wraparound data loss in database。

开启Auto Analyze功能之后，接入节点的系统表没有及时执行auto vacuum，导致后台不断提交带事务的SQL，导致实例报错。

出现版本：

V1.1.38及以下版本。

修复版本：

V1.1.39及以上版本。

建议升级到新版本。

P2

基于分区表创建视图，并对分区列做cast，导致不能使用静态分区裁剪，导致扫描所有分区性能变差。示例SQL如下：

--建viewcreate view test_partition_table_view asSELECTtest_partition_table.ds::text as dsFROMtest_partition_table;--查询sqlSELECT * FROM test_partition_table_view where ds='20211116';

封装成View之后，在优化器中的过滤条件是基于cast之后的列，而非分区列。分区裁剪只能对分区列生效，导致性能变差。

出现版本：

V1.1.38及以下版本。

修复版本：

V1.1.39及以上版本。

  • View中不对分区列进行cast。

  • 建议升级到新版本。

P2

  • 当日期是周日时，执行to_char(xxx, 'Day')函数，实例发生重启。

  • 当日期是周日时，执行to_char(xxx, 'D')函数，结果有误。

当日期是周日时，to_char()函数的底层执行逻辑是toDayOfWeek()，其返回值为7，发生数组越界，导致Hologres实例重启或者结果有误。

出现版本：

V1.1.36及以下版本。

修复版本：

V1.1.37及以上版本。

建议升级到新版本。

P1

实例开启数据脱敏后，子查询（Sub Query）中含有CTE函数，实例短暂出现连接报错或者I/O口报错。

递归调用处理CTE函数时，数据脱敏处理不正确，导致Hologres实例重启。

出现版本：

V1.1.36及以下版本。

修复版本：

V1.1.37及以上版本。

  • 关闭数据脱敏。

  • 建议升级到新版本。

2021年历史缺陷

2021年12月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

为TEXT类型字段设置Dictionary索引时，实例出现短暂重启，示例SQL如下。

call set_table_property('tbl', 'dictionary_encoding_columns', 'a');

，其中a是TEXT类型。

Hologres会给TEXT类型的字段默认设置Dictionary，即为auto属性，手动再给TEXT类型指定Dictionary时，会变为on属性，导致文件状态不一致，无法进行压缩合并（Compaction），从而引发Coredump。

出现版本：

V1.1至V1.1.35及版本。

修复版本：

V1.1.36及以上版本。

  • 手动设置dictionary时，设置为auto属性，即：call set_table_property('tbl', 'dictionary_encoding_columns', 'a:auto');。

  • 建议升级到新版本。

P2

查看慢Query日志时，无法显示查询读取的行数（read_rows）、返回行数（result_rows）等信息。

元仓采集信息不全导致无法显示。

出现版本：

V1.1至V1.1.35及版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本，且需要在查看慢Query的SQL前添加如下命令。

  • set hg_experimental_force_sync_collect_execution_statistics = on;
  • alter database <dbname> set hg_experimental_force_sync_collect_execution_statistics = on;

P1

当SQL的where条件中含有case when xx in ('')时，结果不正确。

Hologres会默认对TEXT类型构建Bitmap，且该列是Nullable属性的情况下，后端对case when xx in ('')生成了错误的执行计划，导致结果不正确。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本。

P1

报错： Cannot reserve capacity larger than 2^31 - 1 for binary\n 。

Hologres会默认对TEXT列构建Dictionary字典编码，当插入的字段太大（单字段超过2GB）时，导致构建的Dictionary过大，查询时报错。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本。

P1

查Binlog时，带有Binlog字段的SQL查主键（PK）字段时查不出数据，不带Binlog的SQL查PK字段时能查询出数据。示例查询（其中a是test表的PK字段）如下。

--带Binlog的SQLSELECT, hg_binlog_lsn ,hg_binlog_event_type,hg_binlog_timestamp_usFROM testwhere a = '723295948321120659';--不带Binlog的SQL“SELECT * FROM testwhere a = '723295948321120659';

后端优化器根据PK字段查询时生成了错误的执行计划，导致查询错误。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本。

P2

实例在CPU负载满的情况下，在HoloWeb中无法查询活跃Query、活跃连接等信息。

在CPU负载满时，pg_stat_activity等系统表会受资源限制，导致查询失败。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本。

P1

使用ANY数组为空时，Hologres实例出现重启。

对于ANY数组为空时后端处理不正确，导致实例Coredump。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

建议升级到新版本。

P1

Query包含Lead或Lag函数，同时函数的第三个参数缺省时报错：Column column5 should be non-nullable but the values contain 1 nulls。

执行器对于Lead和Lag函数的输出结果的Nullable推导不正确，导致报错。

出现版本：

V1.1.34及以下版本。

修复版本：

V1.1.35及以上版本。

建议升级到新版本。

P2

Flink写入Hologres时，有RoaringBitmap字段，写入很慢。

带有RoaringBitmap的写入链路没有在后端优化导致写入性能差。

出现版本：

V1.1.35及以下版本。

修复版本：

V1.1.36及以上版本。

  • 不使用Roaring Bitmap。

  • 建议升级到新版本。

P1

使用Roaring Bitmap时报错：An I/O error occurred while sending to the backend并且在CPU使用率很低时，内存使用率很高。

Roaring Bitmap存在内存泄漏。

出现版本：

V1.1.34及以下版本。

修复版本：

V1.1.35及以上版本。

  • 不使用Roaring Bitmap。

  • 建议升级到新版本。

P1

SQL中有order by时报错：PlStmt Translation: Attribute number 4 not found in project list。

order by会生成sort算子，优化器在生成执行计划时下推错误，导致无法生成执行计划，从而报错。

出现版本：

V1.1.33及以下版本。

修复版本：

V1.1.34及以上版本。

建议升级到新版本。

P1

使用Proxima查询时报错：HGERR_code XX000 HGERR_msge internal error: record batches is empty。

后端读取Proxima的文件状态有误，从而报错。

出现版本：

V1.1.33及以下版本。

修复版本：

V1.1.34及以上版本。

建议升级到新版本。

P2

实例升级至V1.1版本或者在V1.1版本对实例执行升降配等重启操作后，第一次查询时，Query的速度变慢，查看执行计划，统计信息不准确。再次执行Query，统计信息正确且性能恢复。

实例升级重启后，第一次执行Query时未能拿到正确的统计信息版本，导致统计信息不准确，性能变差。

出现版本：

V1.1至V1.1.32版本。

修复版本：

V1.1.33及以上版本。

  • 可以多次执行Query，使得统计信息变正确，恢复性能。

  • 建议升级到新版本。

P0

使用drop/truncate命令时同时查询表，造成实例重启。

查询结束到数据析构之间，发生表的drop/truncate，造成实例coredump，从而重启。

出现版本：

V1.1.32及以下版本。

修复版本：

V1.1.33及以上版本。

建议升级到新版本。

P1

升级至V1.1版本后，多表（十几个表）Join出现OOM异常，且升级前运行正常。

优化器预估表的行数过多，导致执行器在初始化阶段OOM，无法进行下一步计算。

出现版本：

V1.1至V1.1.31版本。

修复版本：

V1.1.32及以上版本。

建议升级到新版本。

P2

Serving点查场景，因为客户端凑批导致延迟变高。

每个Worker节点上只有一个点查写入节点，当请求都发到写入节点时容易产生凑批行为，而当前凑批上限过大，导致等待攒批耗时较长，造成点查延迟变高。

出现版本：

V1.1至V1.1.31版本。

修复版本：

V1.1.32及以上版本。

建议升级到新版本。

P1

存储加密的表limit offset命令不加order by limit能查到结果，加了就查不出结果。

对于存储加密的表，没有按照文档正确的配置进行操作，生成了错误版本，导致内存表（MemTable）数据丢失，从而无法出结果。

出现版本：

V1.1至V1.1.31版本。

修复版本：

V1.1.32及以上版本。

建议升级到新版本。

P1

执行Truncate命令时，当表名称有大写时会报错找不到表。例如执行#truncate "Abc";，报错：ERROR: relation "abc" does not exist。

当前Truncate对大小写处理逻辑错误。

出现版本：

V1.1.30及以下版本。

修复版本：

V1.1.31及以上版本。

建议升级到新版本。

P1

使用函数to_char、to_date和to_timestamp时报错：time after 2282 not supported。

函数to_char、to_date和to_timestamp支持的时间范围是1925 ~ 2282年，超出时间范围就会报错。

出现版本：

V1.1.30及以下版本。

修复版本：

V1.1.31及以上版本。

建议升级到新版本，升级后可以通过GUC控制时间范围，支持所有时间的数据，如下所示。

  • set hg_experimental_functions_use_pg_implementation = ‘to_char’; 。

  • set hg_experimental_functions_use_pg_implementation = ‘to_date’; 。

  • set hg_experimental_functions_use_pg_implementation = ‘to_timestamp’;。

P1

SQL中有内连接（inner join），执行后运算结果偏少。

Join算子要求相同的join key数据分布推导在相同并发节点，实际执行时，数据分布推导错误，会错误地将相同数据Shuffle到不同的节点，导致Join结果错误，表现为结果比实际少。

出现版本：

V1.1.30及以下版本。

修复版本：

V1.1.31及以上版本。

建议升级到新版本。

P1

执行SQL时报错：Query could not generate plan by Hologres : PlStmt Translation: Attribute number 4 not found in project list。

表连接时没有Join Key，导致执行计划生成失败报错。

出现版本：

V1.1至V1.1.27版本。

修复版本：

V1.1.28及以上版本。

  • 重新建表，然后执行analyze table命令。

  • 建议升级到新版本。

P1

使用get_json_object函数时报错：Column column0 should be non-nullable but the values contain 1 nulls。

get_json_object函数的两个参数为非Nullable类型，但是UDF的结果可能为Nullable类型，在生成执行计划时，检查非Nullable失败，导致报错。

出现版本：

V1.1.27及以下版本。

修复版本：

V1.1.28及以上版本。

建议升级到新版本。

P1

报错：ERROR: Build query failed: Table group [] FROM table must equals table group [] FROM QO.。

执行计划生成中，DML节点对下游TG有信息要求，但下游某节点推断出的TG属性为NULL，没有满足DML的TG要求，导致报错。

出现版本：

V1.1.27及以下版本。

修复版本：

V1.1.28及以上版本。

建议升级到新版本。

P1

执行DROP TABLE命令时卡死，且重试之后CPU突然飙高。

实例开启了Auto Analyze，Auto Analyze会加share_update_exclusive锁， 同时Auto Analyze会使用连接，新的连接load_stats，会加access_shared_lock；这两个步骤期间，如果用户进行DROP TABLE 就会卡死。

出现版本：

V1.1.27及以下版本。

修复版本：

V1.1.28及以上版本。

  • 建议在业务低峰期开启Auto Analyze功能。

  • 建议升级到新版本。

2021年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2（优化）

当实例重启后，查询部分数据结果不一致。

后端某一个节点重启后，需要与其他节点版本追齐，在追齐过程中，重启的节点版本较低，查询的还是原数据，导致结果查询不一致。优化后的行为是，当节点重启后，若是与其他节点版本不一致，则不提供服务，直到追齐版本后再提供服务，保证数据一致性。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

建议升级到新版本。

P2

MaxCompute数据导入时，执行set hg_experimental_foreign_table_split_size = 64; INSERT INTO public.lineitem SELECT * FROM public.odps_lineitem_1t ;时内存很高或者报错OOM，当设置参数值为128时，则没有问题。

底层在Meta中，加载了所有StripesMeta导致内存飙高。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

  • 暂时不使用set hg_experimental_foreign_table_split_size = 64;命令。

  • 建议升级到新版本。

P1

当对Distribution Key或者Primary Key使用IN操作，IN数组超过100个的时候，导致最终结果不正确。

当IN超过100个后，Shard pruning之后的Shard数量随机变化，导致生成的计划错误，结果不正确。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

  • 减少IN的数量至100以内。

  • 建议升级到新版本。

P1

在外部表数据导入内部表的时候，先insert 然后delete历史数据，但是insert 语句取出来的分区不是最新分区，导致插入数据为0。

在导入过程中，存在存储器异常问题，导致未获取到最新数据。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

建议升级到新版本。

P1

当行很宽，数据量超过数百MB时，单行记录就超出了RECORDBATCH记录批规格的上限，就会输出0行的RECORDBATCH，从而引发缺陷，实例进行重启。

当行很宽时，后端对行数的处理不够，导致实例进行重启。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

建议升级到新版本。

P2

报错：internal error: string decimal literal can not be tentative。

SQL中有in表达式，例如：SELECT * FROM tbl where col in (1.11, 1.2, 1.333);当in表达式里面的DECIMAL精度不一致的时候，后端计算引擎处理结果不一致导致报错。

出现版本：

V1.1.24及以下版本。

修复版本：

V1.1.26及以上版本。

  • in表达式里只用一个数据。

  • 建议升级到新版本。

P2（优化）

报错：org.postgresql.util.PSQLException: ERROR: Total memory used by all existing queries exceeded memory limitation 20132659200: xxxxx bytes used.。

单个节点计算内存超过20GB的上限（单个节点总上限是64GB，1/3用于计算，1/3用于缓存，1/3用于元数据）。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

在V1.1.24版本支持单个节点内存弹性调整，后台会检测当前节点内存的使用状态，弹性调整计算内存大小，缓解20G计算内存上限的问题。但是Query还是报错，建议优化SQL或者扩容。

P1

报错：ERROR: Query could not generate plan by Hologres : Query Translation: No attribute entry found due to incorrect normalization of query。

执行的sql中，选中的列不在GROUP BY子句里面，但主键是GROUP BY子句的子集，Query无法生成计划，从而导致报错。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

建议升级到新版本。

P1

使用Flink或者Holo Client，往Binlog表里一次写入多条重复的数据，中间数据的Binlog丢失。

写Binlog表，其中有重复的数据时，后端执行器会只生成最后一条数据的Binlog，其他重复的数据会被忽略。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

建议升级到新版本。

P0

查询MaxCompute外部表时，最后两行数据会随机变化，数据类型是DECIMAL类型。

直读MaxCompute的ORC格式数据，当文件中存在DECIMAL类型，存储优化时，Hologres读出来的DECIMAL统计信息存在随机问题。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

建议升级到新版本。

P1

报错：Remote seek with parameters is not supported。

sort算子默认具有rewindable属性，但底层并不支持，Query生成计划时报错。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

建议升级到新版本。

P1

在HologresV1.1版本设置了资源组，但是在跑Query时OOM（Out Of Memory），出现报错：used by all existing queries exceeded memory limitation，即使不跑任何Query，查询慢SQL和活跃Query这些也报错OOM。

QE内存使用超过阈值，跑新Query超过资源组配额，异常时会导致内存泄漏。

出现版本：

V1.1至V1.1.23版本。

修复版本：

V1.1.24及以上版本。

  • 重新新建资源组。

  • 建议升级到新版本。

P2

偶发报错：fail to setremoteost invalid remon ip。

后台进程在检查IP白名单的变量时，变量没有初始化导致偶发报错。

出现版本：

V1.1.23及以下版本。

修复版本：

V1.1.24及以上版本。

  • 请重试几次。

  • 建议升级到新版本。

P1

对表执行Analyze或者auto analyze时，当表中存在同名但是大小写不同的列名时，报错：CheckSchema failed。

Frontend节点在从优化以后的树结构里面转化成PowerBuilderTree的时候对应列的序号找错，导致报错。

出现版本：

V1.1.22及以下版本。

修复版本：

V1.1.23及以上版本。

建议升级到新版本。

P1

执行多表RightOuterJoin的SQL时，不带有limit子句查询结果仅一条，加上limit子句之后会出现多条重复的数据。

实现RightOuterJoin的时候，在优化器中生成了错误的计划，导致最终结果数据重复。

出现版本：

V1.1.22及以下版本。

修复版本：

V1.1.23及以上版本。

建议升级到新版本。

P1

在case when语句中，TEXT字段同时作为group by 和agg的参数时，无法生成计划，出现报错：ERROR: Query could not generate plan by Hologres : PlStmt Translation: Attribute number 46046320 not found in project list。

在case when中取法找到agg参数字段的colref导致计划无法生成。

出现版本：

V1.1.22及以下版本。

修复版本：

V1.1.23及以上版本。

建议升级到新版本。

P1

报错：ERROR: internal error: Writing column: item_emb with array size: 682790219 violates fixed size list (32) constraint declared in schema。

const数组优化机制在SE没有判断导致执行出错。

出现版本：

V1.1至V1.1.21版本。

修复版本：

V1.1.22及以上版本。

建议升级到新版本。

P0

使用insert on conflict do update set语句时，语句的subquery中将多行值赋给一行，例如SET(mes1, mes2) = (SELECT mes1, mes2 FROM insert_on_conflict_do_update_negative_source)导致实例重启。

subquery中将多行值赋给一行的语法产生了多表达式参数，此参数没有进行转换支持column id信息不存在，导致实例重启。

出现版本：

V1.1.21及以下版本。

修复版本：

V1.1.22及以上版本。

建议升级到新版本。

P2

对于DECIMAL数据相乘报错：code: kActorInvokeError msg: "HGERR_code 22003 HGERR_msge numeric field overflow HGERR_detl A field with precision 38, scale 36 must round to an absolute value less than 10^2. HGERR_ctxt HGERR_erno 2 HGERR_end" err_data { filename: "FunctionsCast.cc" lineno: 323 funcname: "DecimalOverflowCheck" sqlerrcode: 50331778 message: "numeric field overflow" detail: "A field with precision 38, scale 36 must round to an absolute value less than 10^2." context: "。

对于DECIMAL类型的字段进行相乘，例如：numeric(38, 18)乘以numeric(38, 18)会得到numeric(38, 36)，小数点保存太多位数导致溢出，从而报错。

出现版本：

V1.1.21及以下版本。

修复版本：

V1.1.22及以上版本。

  • 使用round函数进行绕过。

  • 建议升级到新版本。

2021年09-10月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

报错："database is not accepting commands to avoid wraparound data loss in database ""template0""。

后台会给Query设置自增transaction id，对于QPS高的实例，ID会超过INT上界，从而导致报错。

出现版本：

V0.10.19至V0.10.42版本。

修复版本：

V1.1及以上版本。

建议升级到新版本。

P1

数据局部列更新入表偶发报错：internal error: Record batch has 519 rows but length of columns is 7407。

字段中包含TEXT[]，当前TEXT[]没有进行二层数组的slice()，导致其长度不正确，在执行reverse()命令时取到了-1导致超过容量。

出现版本：

V0.10.41。

修复版本：

V0.10.42及以上版本。

  • 通过set hg_experimental_skip_mem_table=on命令暂时绕过。

  • 建议升级到新版本。

P1

使用hg_create_table_like创建行存表，对行存表插入数据时报错：ERROR: internal error: Cannot find index full ID: 51539607554 (table id: 12, index id: 2) in storages or it is deleting!。

行存表中有多个主键，获取表主键的时候是需要执行多次hg_create_table_like，将主键的列取出来放到Set集合里面，导致顺序丢失。

出现版本：

V0.10.42。

修复版本：

V0.10.45及以上版本。

  • 手动执行create语句创建行存表。

  • 建议升级到新版本。

P2

删除分区时报错：FAILED: ERROR: query id[27xxxxxxxxxxxxxx37] SE object lock failed。

删除分区时，Query被后端异常退出，导致报错。

出现版本：

V0.10.41及以下版本。

修复版本：

V0.10.42及以上版本。

  • 不对该表进行操作。

  • 联系值班重启实例。

  • 建议升级到新版本。

P2

查询或者写入数据时报错：ERROR: internal error: Invalid table id : 641 MDTableGroup

一般是因为刚做完DDL，后端节点还在重启，这个时候执行DML，就会导致节点间的版本不一致而报错。

出现版本：

V1.1.18及以下版本。

修复版本：

V1.1.19及以上版本。

  • 等待一段时间重试。

  • 建议升级到新版本。

2021年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

表开启Hologres Binlog，且建表时Binlog的TTL设置比较小的时间，但表的存储数据一直增长（业务数据量并没有增加）。

建表（create table）时，显式指定的Binlog TTL未真正生效，默认为100年。

出现版本：

V0.10版本。

修复版本：

V1.1版本。

  • 需要重新手动更改表Binlog TTL为较小的值，执行call set_table_property('schema.table', 'binlog.ttl', '86400');

  • 建议升级到V1.1版本。

P1

列存表频繁进行Update、Delete、Insert on Conflict操作，引起存储空间持续增长。

Hologres为提高更高的效率，采用标记删除算法，当文件中被标记记录达到一定比率，会触发后台Compaction进程，进行空间的释放。Hologres存在缺陷，在某些情况下Compaction未启动。

出现版本：

V0.10.25以下版本。

修复版本：

V0.10.25及以上版本。

建议升级到最新版本。

P1

当表正在实时写入（通过Flink、数据集成等方式）时，同时查询数据报错：ERROR: internal error: Record batch has 742 rows but length of columns is 749. columns=[ColumnHandle(type=string)(table_column_id=3), ColumnHandle(type=string)(table_column_id=4), ColumnHandle(type=string)(table_column_id=5)]。

实时写入时，数据是先写入MemTable再落到磁盘，在写入期间去查询，查询列标记长度和真实数据长度未对齐，导致查询失败报错。

出现版本：

V0.10.41版本。

修复版本：

V0.10.42及以上版本。

建议升级到最新版本。

P1

业务没有增加，内存突然增长。

SQL中有如下函数，会出现内存泄漏，导致内存突然增长。

  • extract(xxx FROM time)

  • extract(xxx FROM interval)

  • date_part(xx, interval)

出现版本：

V0.10.31以下版本。

修复版本：

V0.10.32及以上版本。

  • 不使用列表中的函数。

  • 建议升级到最新版本。

P2

提示报错：time before epoch time not supported。

SQL中使用了to_char、to_date和to_timestamp这些函数的其中一个或多个，且数据有1970年之前的数据，Hologres不支持1970年之前的数据。

出现版本：

V0.10及以下版本。

修复版本：

V1.1版本。

  • 过滤1970年之前的数据。

  • 建议升级到最新版本，可支持1925-2282年的数据。

P2

非Superuser执行SELECT hg_dump_script('xxxx')函数时报错：ERROR: permission denied for table pg_subscription 。

hg_dump_script间接调用了pg_subscription这个relation，但是pg_subscription里面可能会存在敏感信息，默认只有Superuser才可以访问这个表。

出现版本：

V0.10版本。

修复版本：

V1.1版本。

  • pg_subscription并未实际存储对于hg_dump_script有用的信息，已修改该默认行为，在V1.1版本解决。

  • 遇到没有权限问题，可以给当前用户授予pg_subscription的访问权限

P2

SQL中含有left join，不带有limit子句查询结果仅一条，加上limit之后会出现多条重复的数据。

left join在底层会转换成right outer join，引擎在实现right outer join的时候，生成的right side走broadcast的错误执行计划，导致最终结果数据重复，可以通过执行explain sql查看执行计划是否走broadcast。

出现版本：

V0.10.40及以下版本。

修复版本：

V1.1版本。

建议升级到最新版本。

P2

往Binlog表里一次写入多条重复的数据时，中间数据的Binlog会丢失，未保留所有Binlog中间状态变化。

重复数据会被引擎去重，默认保留最后一条，导致中间状态变化丢失。

出现版本：

V0.10.30及以下版本。

修复版本：

V0.10.39及以上版本。

建议升级到最新版本。

P2

提示报错：ERROR: status { code: SERVER_INTERNAL_ERROR message: " HGERR_code 00000 HGERR_msge OptimizedRegularExpression: cannot compile re2: \\c, error: invalid escape sequence: \\c4 HGERR_end[query_id:xx" err_data { message: "OptimizedRegularExpression: cannot compile re2: \\c, error: invalid escape sequence: \\c4" context: "[query_id:xxx]" } }CONTEXT: [query_id:xx]。

SQL中的like有\ + 字符或数字的情况，示例SQL如下。

SELECT * FROM test_tb where a like '%\c%';SELECT * FROM test_tb where a like '%F\G%';

目前引擎对于SQL中的like有\ + 字符或数字的情况处理不够完善，导致报错。

出现版本：

V0.10.38及以下版本。

修复版本：

V0.10.39及以上版本。

建议升级到最新版本。

P2

行存表根据主键查询时，结果不一致或者报错：Duplicate keys detected when building hash table。

建行存表时，主键和Clustering Key的顺序指定不一致，如

create table k ( a int, b int, primary key(a, b));call set_table_property('k', 'orientation', 'row');call set_table_property('k', 'clustering_key', 'b,a');

出现版本：

V0.10.37及以下版本。

修复版本：

V0.10.38及以上版本。

  • 重新建表，将主键和Clustering Key的顺序保持一致。

  • 建议升级到新版本。

P2

在新建的schema下使用数据脱敏，查询脱敏数据时报错：hg_anon_mask_name(text) doesnt exist。

数据脱敏函数被创建在public schema下，导致在新schema下无法查询脱敏数据。

出现版本：

V0.10.35及以下版本。

修复版本：

V0.10.36及以上版本。

  • 只在public schema下使用数据脱敏函数。

  • 建议升级到新版本。

P2

报错：internal error:string decimal literal can not be tentative。

SQL语句里in中包含不同精度的decimal数据，示例SQL如下。

SELECT * FROM table where sval in(170344.964,1339107.84);

出现版本：

V0.10.34及以下版本。

修复版本：

V0.10.35及以上版本。

  • 修改SQL语句里in中包含的decimal数据精度一致。

  • 建议升级到最新版本。

2021年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

RoaringBitmap字段被配置为字典编码（Dictionary Encoding）时，造成写入失败，实例不可查询。

RoaringBitmap类型并不支持字典编码，强行设置造成编码逻辑故障，导致写入一直失败。

出现版本：

V0.10.24及以下版本。

修复版本：

V0.10.25及以上版本。

  • RoaringBitmap字段取消Dictionary Encoding。

  • 建议升级到新版本。

P0

在非public schema执行add comment on tablename is "is comment" 导致写入或查询卡住。

在非public schema下执行add comment操作：add comment on tablename is "comment"，SQL语句中未指定Schema名，导致单个节点异常，从而导致出现写入/查询卡住现象。

出现版本：

V0.10.20及以下版本。

修复版本：

V0.10.21及以上版本。

  • SQL中add comment时加上Schema名：add comment on schema.tablename is "comment"。

  • 建议升级到新版本。

P0

报错：cannot acquire lock in time。

在原有的版本中，会对DDL加锁，高并发查询和删除（Drop）同一张表时，后端节点出现死锁，导致有关这张表的操作都卡住，从而报错

出现版本：

V0.9.22及以下版本。

修复版本：

V0.9.23及以上版本。

建议升级到新版本。

P1

在数据没有写入时，存储空间持续线性增长。

使用insert on conflict do update set pk =pk语句导入数据，实际上导入前和导入后数据并没有实际变化，触发底层优化BUG，导致存储线性增长。

出现版本：

V0.10.23及以下版本。

修复版本：

V0.10.24及以上版本。

  • 可以通过执行insert into values语句，触发数据更新，多余的数据将会被删除。

  • 建议升级到新版本。

P1

在执行extract XXX FROM timestamptz/timestamp时，提示报错：time before epoch time not supported。

EXTRACT函数在处理数据中的NULL值会有误。

出现版本：

V0.10.20及以下版本。

修复版本：

V0.10.21及以上版本。

  • SQL通过过滤条件过滤掉NULL。

  • 建议升级到新版本。

P1

报错：cant determine shard id of shard value。

SQL语句中有union all语句，并且Group by字段中有distribution key，导致执行计划错误，从而导致找不到对应的Shard。

出现版本：

V0.10.20及以下版本。

修复版本：

V0.10.21及以上版本。

建议升级到新版本。

P1

ERROR: Query could not generate plan by gporca : Group by key is type of unsupported type. not supported

Group by的字段类型是非精确类型，导致出现报错。

出现版本：

V0.9及以下版本。

修复版本：

V0.10已开发限制。

  • Group by中避免非精确数据类型。

  • 建议升级到新版本。

P1

读外表时报错：unsupported column type:list。

在MaxCompute已有表中新增一列array column且该列不导入数据，外表查询该MaxCompute时报错

出现版本：

V0.9.22及以下版本。

修复版本：

V0.9.23及以上版本。

  • MaxCompute新增一列array column后，即时为该列写入数据。

  • 建议升级到新版本。

P1

报错ERROR: internal error: The left child should be column ref, num_children: 1。

查询的SQL中，Clustering key为varchar类型就会触发。

出现版本：

V0.9.24及以下版本。

修复版本：

V0.9.25及以上版本。

  • 将varchar字段改成TEXT字段。

  • 建议升级到新版本。

P2

查询外表报错：code: SERVER_INTERNAL_ERROR message: "query next FROM foreign table executor failed，Unknown file type: xxx

MaxCompute集群发生配置更新，同时Hologres依赖的外表元数据未及时更新导致。

出现版本：

V0.10.20及以下版本。

修复版本：

V0.10.21及以上版本。

无法规避，需要实例重启或者升级到新版本。

上一篇：默认行为变更说明下一篇：公告