关键缺陷通知

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

背景信息

  • 缺陷及修复说明

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

      例如,1.3版本中存在某缺陷,在1.1或0.10等版本中大多数存在,少数不存在场景有明确标注。

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

      例如,1.1版本中已修复的某缺陷,在1.1或1.3等版本中均已修复。

  • 缺陷等级说明

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

    • P1:推荐升级,提前规避相关问题。

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

2024年缺陷

2024年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

p2

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

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

出现版本:3.0.11及以下版本。

修复版本:3.0.12及以上版本。

升级到最新版本。

说明

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

p2

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

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

出现版本:3.0.9及以下版本。

修复版本:3.0.10及以上版本。

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

  • 升级到最新版本。

p2

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

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

出现版本:3.0.9及以下版本。

修复版本:3.0.10及以上版本。

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

  • 升级到最新版本。

p2

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

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

出现版本:

  • 3.0.8及以下版本。

  • 2.2.33及以下版本。

修复版本:

  • 3.0.9及以上版本。

  • 2.2.34及以下版本。

升级到最新版本。

p2

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

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

出现版本:

  • 3.0.8及以下版本。

  • 2.2.31及以下版本。

修复版本:

  • 3.0.10及以上版本。

  • 2.2.32及以下版本。

升级到最新版本。

p2

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

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

出现版本:2.2.30及以下版本。

修复版本:2.2.31及以上版本。

升级到最新版本。

P2

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

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

出现版本:

  • 2.2.22及以上版本。

  • 3.0.1及以上版本。

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

ALTER DATABASE db_name SET hg_experimental_query_length_limit = 0;

2024年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

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

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

出现版本:2.2.24及以下版本。

修复版本:2.2.25及以上版本。

升级到最新版本。

P2

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

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

出现版本:2.2.24及以下版本。

修复版本:2.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被破坏,从而出现报错。

出现版本:

  • 2.2.23及以下版本。

  • 3.0.3及以下版本。

修复版本:

  • 2.2.24及以上版本。

  • 3.0.4及以上版本。

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

  • 升级到最新版本。

P2

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

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

出现版本:2.2.22及以下版本。

修复版本:2.2.23及以上版本。

升级到最新版本。

P2

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

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

出现版本:2.2.21及以下版本。

修复版本:2.2.22及以上版本。

升级到最新版本。

P2

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

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

出现版本:2.1.1及以上版本。

修复版本:等待修复。

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

  • 改写SQL,示例如下:

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

P2

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

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

出现版本:低于2.2.23,2.1.43,2.0.46,1.3.71的版本。

修复版本:3.0.4,2.2.23,2.1.43,2.0.46,1.3.71及以上版本。

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

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

2024年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:2.1.1至2.2.21版本。

修复版本:2.2.22及以上版本。

升级到最新版本。

P1

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

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

出现版本:

  • 2.0.1~2.0.43版本。

  • 2.1.1~2.1.36版本。

  • 2.2.1~2.2.8版本。

修复版本:

  • 2.0.44及以上的2.0版本。

  • 2.1.37及以上的2.1版本。

  • 2.2.9及以上的2.2版本。

升级到最新版本。

2024年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

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

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

出现版本:1.3及以上版本。

修复版本:2.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执行,影响查询性能。

出现版本:2.2.1至2.2.18版本。

修复版本:2.2.19及以上版本。

  • 升级到最新版本。

  • 将COUNTDISTINCT替换为UNIQ。

P2

慢Query日志(query_log表)中query_start字段的日期格式为2024-07-08 22:00:00,而query_date字段日期格式为19700101

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

出现版本:2.2.1至2.2.18版本。

修复版本:2.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的检查,从而导致脏数据成功写入。

出现版本:2.2.1至2.2.18版本。

修复版本:2.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在解析日期函数时计算时区错误,导致结果错误。

出现版本:2.2.1至2.2.18版本。

修复版本:2.2.19及以上版本。

升级到最新版本。

P2

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

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

出现版本:2.2.1至 2.2.18版本。

修复版本:2.2.19及以上版本。

升级到最新版本。

P0

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

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

出现版本:2.2.1至2.2.17版本。

修复版本:2.2.18及以上版本。

升级到最新版本。

2024年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

执行hg_insert_overwriteCREATE TABLE AS

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

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

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

出现版本:

2.2.1至2.2.14版本。

修复版本:

2.2.15及以上版本。

升级到最新版本。

P1

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

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

出现版本:

2.2.13及以下版本。

修复版本:

2.2.14及以上版本。

升级到最新版本。

p2

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

Paimon中VARCHAR类型的数据:中国
写入Hologres后的VARCHAR类型的数据为:???(乱码)

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

出现版本:

2.2.12及以下版本。

修复版本:

2.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不一致。

出现版本:

2.1.37及以下版本。

修复版本:

  • 2.1.38及以上版本。

  • 2.2.10及以上版本。

升级到最新版本。

2024年05月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

2.2.8及以下版本。

修复版本:

2.2.9及以上版本。

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

  • 升级到最新版本。

P1

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

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

出现版本:

  • 2.1.16至2.1.23版本。

  • 2.0.0至2.0.41版本。

修复版本:

  • 2.1.24及以上版本。

  • 2.0.42以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.1.25至2.1.32版本。

修复版本:

2.1.33及以上版本。

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

  • 升级到最新版本。

P2

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

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

出现版本:

2.0.31及以下版本

修复版本:

2.0.32及以上版本。

升级到最新版本。

2024年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

2.0.31版本。

修复版本:

2.1.27及以上版本。

升级到最新版本。

P2

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

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

说明

实例中的内存并没有真正上涨,只是监控统计重复。

出现版本:

2.1.26版本。

修复版本:

2.1.27及以上版本。

升级到最新版本。

P1

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

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

出现版本:

2.1.1至2.1.25版本。

修复版本:

2.1.26及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.1.1至2.1.25版本。

修复版本:

2.1.26及以上版本。

升级到最新版本。

P1

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

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

出现版本:

VVR 6.0.7以下版本。

修复版本:

VVR 6.0.7及以上版本。

升级到最新版本。

2024年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

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

  • 内存持续上涨。

  • 大量锁占用。

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

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

出现版本:

2.1.23至2.1.24版本。

修复版本:

2.1.25及以上版本。

升级到最新版本。

P1

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

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

出现版本:

2.1.21及以下版本。

修复版本:

2.1.22及以上版本。

升级到最新版本。

P1

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

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

出现版本:

2.1.1至2.1.9版本。

修复版本:

2.1.10及以上版本。

升级到最新版本。

P1

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

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

出现版本:

  • 2.1.2至2.1.8版本。

  • 2.0.23至2.0.30版本。

修复版本:

  • 2.1.9及以上版本。

  • 2.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函数的处理导致执行计划不正确,结果出现错误。

出现版本:

2.1.21及以下版本。

修复版本:

2.1.22及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.1.0至2.1.14版本。

修复版本:

2.1.15及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.0及以下版本。

修复版本:

2.1.0及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.0及以下版本。

修复版本:

2.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 ")"

出现版本:

2.1.20及以下版本。

修复版本:

2.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停滞。

出现版本:

2.1.20及以下版本。

修复版本:

2.1.21及以上版本。

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

  • 升级到最新版本。

P2

Query的过滤条件(where)中包含Clustering Key,且使用Order By对Clustering Key排序,如where a >= xxx limit x order by aa列是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的结果不正确。

出现版本:

2.1.19及以下版本。

修复版本:

2.1.20及以上版本。

升级到最新版本。

P1

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

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

出现版本:

2.1.10至2.1.18版本。

修复版本:

2.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时,会导致将数据截断再计算,从而出现结果不符合预期。

出现版本:

2.1.18及以下版本。

修复版本:

2.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会变慢。

出现版本:

2.1.1至2.1.14版本。

修复版本:

2.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函数计算有常量时下推错误,从而出现报错。

出现版本:

  • 2.1.1至2.1.14版本。

  • 2.0.34及以下版本。

修复版本:

  • 2.1.15及以上版本。

  • 2.0.35及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.1.1至2.1.12版本。

修复版本:

2.1.13及以上版本。

升级到最新版本。

P2

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

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

出现版本:

  • 2.1.1至2.1.11版本。

  • 2.0.33及以下版本。

修复版本:

  • 2.1.12及以上版本。

  • 2.0.34及以上版本。

升级到最新版本。

P2

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

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

出现版本:

  • 2.1.0至2.1.2版本。

  • 2.0.5及以下版本。

修复版本:

  • 2.1.3及以上版本。

  • 2.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数后,元数据未被更新,导致实例出现短暂重启。

出现版本:

  • 2.1.1至2.1.10版本。

  • 2.0.33及以下版本。

修复版本:

  • 2.1.11及以上版本。

  • 2.0.34版本。

升级到最新版本。

P2

使用存储过程(hg_insert_overwrite)导入数据失败后,临时表未被清理。

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

出现版本:

2.0.19及以下版本。

修复版本:

2.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类型精度处理有误,导致数据错误。

出现版本:

2.1.11及以下版本。

修复版本:

2.1.12及以上版本。

说明

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

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

  • 升级到最新版本。

P1

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

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

出现版本:

2.1.1至2.1.9版本。

修复版本:

2.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类型时,类型转换错误,导致结果不正确。

出现版本:

2.0.27及以下版本。

修复版本:

2.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函数中大写字段,导致查询报错。

出现版本:

2.0.1至2.0.25版本。

修复版本:

2.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处理有误,导致执行计划错误,从而查询报错。

出现版本:

2.0.25及以下版本。

修复版本:

2.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个分区节点给优化掉,导致返回结果不正确,从而列的别名丢失。

出现版本:

2.0.25及以下版本。

修复版本:

2.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的精度未被正常转换,导致结果精度无法对齐而报错。

出现版本:

2.0.23及以下版本。

修复版本:

2.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操作时,未正确判断父子表关系,导致报错。

出现版本:

2.0.23及以下版本。

修复版本:

2.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,从而导致主键重复。

出现版本:

2.0.22及以下版本。

修复版本:

2.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报错。

出现版本:

2.0.22及以下版本。

修复版本:

2.0.23及以上版本。

升级到最新版本。

P2

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

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

出现版本:

1.3.40至1.3.51版本。

修复版本:

1.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) 时系统不匹配,从而报错。

出现版本:

2.0.21及以下版本。

修复版本:

2.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重启,引起应用层访问外部表偶发出现报错。

出现版本:

2.0.15至2.0.20版本。

1.3.61至1.3.62版本

修复版本:

2.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,导致结果错误,从而出现报错。

出现版本:

2.0.20及以下版本。

修复版本:

2.0.21及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.0.20及以下版本。

修复版本:

2.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时结果出错。

出现版本:

2.0.19及以下版本。

修复版本:

2.0.20及以上版本。

升级到最新版本。

P2

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

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

出现版本:

2.0.17-2.0.19。

修复版本:

2.0.20及以上版本。

升级到最新版本。

P2

string_aggarray_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_aggarray_agg在有agg filter的情况下,未能正确处理filter,导致结果错误或者filter结果不稳定。

出现版本:

2.0.18及以下版本。

修复版本:

2.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。

出现版本:

2.0.18及以下版本。

修复版本:

2.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检验不通过,导致实例重启。

出现版本:

2.0.18及以下版本。

修复版本:

2.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下创建同名表时,自动分区配置冲突,从而出现报错。

出现版本:

2.0.18及以下版本。

修复版本:

2.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函数入参为单列,导致报错。

出现版本:

2.0.17及以下版本。

修复版本:

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

出现版本:

2.0.17及以下版本。

修复版本:

2.0.18及以上版本。

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

    begin;call set_table_property('schema.<冷存子表名>', 'storage_mode', 'hot');call set_table_property('schema.<冷存子表名>', 'storage_mode', 'cold');commit;
  • 建议升级到最新版本。

    说明

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

P2

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

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

出现版本:

1.3和2.0早期版本。

修复版本:

1.3.61、2.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在生成执行计划时,没有将类型对齐,导致最终输出结果与预期有差异。

出现版本:

1.3.59及以下版本和

2.0.14及以下版本。

修复版本:

1.3.60及以上版本和2.0.15及以上版本。

建议升级到最新版本。

P2

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

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

出现版本:

1.3.42至2.0.16版本。

修复版本:

2.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进程的查询请求。

出现版本:

2.0.1至2.0.11版本。

修复版本:

2.0.12及以上版本。

建议升级到最新版本。

P2

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

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

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

出现版本:

2.0.15及以下版本。

修复版本:

2.0.16及以上版本。

建议升级到最新版本。

P2

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

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

出现版本:

2.0.15及以下版本。

修复版本:

2.0.16及以上版本。

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

  • 建议升级到最新版本。

P2

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

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

出现版本:

2.0.12至2.0.14版本。

修复版本:

2.0.15及以上版本。

建议升级到最新版本。

P2

case when查询中有array[]类型,查询报错:

Filter has x rows but length of columns is y

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

出现版本:

2.0.10及以下版本。

修复版本:

2.0.11及以上版本。

建议升级到最新版本。

P2

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

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

出现版本:

2.0.12及以下版本。

修复版本:

2.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或者查询/写入对应表报错。

出现版本:

1.3.55及以下版本。

修复版本:

1.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列重复,子查询查出来不止一行,从而导致结果错误。

出现版本:

2.0.3至2.0.9版本。

修复版本:

2.0.10及以上版本。

建议升级到最新版本。

P2

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

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

出现版本:

1.3.54及以下版本。

修复版本:

1.3.55及以上版本。

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

  • 建议升级到最新版本。

P2

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

ERROR: pooler: xxxx: authentication failed

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

出现版本:

1.3.54及以下版本。

修复版本:

1.3.55及以上版本。

建议升级到最新版本。

P2

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

show max_connections;

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

出现版本:

1.3.54及以下版本。

修复版本:

1.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,从而查询报错。

出现版本:

1.3.51及以下版本。

修复版本:

1.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标准协议一致,查询结果相比老版本结果中将会有转义符号(\),因此结果不一致是符合预期的。

出现版本:

1.3.50及以下版本。

修复版本:

1.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优化掉,导致表的列对不齐,从而查询报错。

出现版本:

1.3.45及以下版本。

修复版本:

1.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类型数据。

出现版本:

1.3.20至1.3.46版本。

修复版本:

1.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对于科学计数法目前处理不当,导致查询结果不正确。

出现版本:

1.3.44及以下版本。

修复版本:

1.3.46及以上版本。

建议升级到最新版本。

P2

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

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

出现版本:

1.3.20至1.3.40版本。

修复版本:

1.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。

出现版本:

1.3.20至1.3.44版本。

修复版本:

1.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

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

出现版本:

1.3.20至1.3.43版本。

修复版本:

1.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。因此无法运行导致报错。

出现版本:

1.3.20至1.3.41版本。

修复版本:

1.3.42及以上版本。

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

  • 建议升级到最新版本。

P2

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

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

出现版本:

1.3.20至1.3.41版本。

修复版本:

1.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发现精度不一致,从而查询报错。

出现版本:

1.3.20至1.3.40版本。

修复版本:

1.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等属性,如果修改则会报错。

出现版本:

1.3.38至1.3.40版本。

修复版本:

1.3.41及以上版本。

建议升级到最新版本。

说明

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

P2

to_dateto_charto_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_dateto_charto_timestamp函数对空格处理有误,导致数据转换失败,从而查询报错。

出现版本:

1.3.20至1.3.40版本。

修复版本:

1.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数组的双向转换,所以执行失败。

出现版本:

1.3.37及以下版本。

修复版本:

1.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没有下推,导致查询结果不正确。

出现版本:

1.3.20至1.3.36版本。

修复版本:

1.3.37及以上版本。

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

  • 建议升级到最新版本。

P2

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

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

出现版本:

1.3.36版本。

修复版本:

1.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下没有此表,导致报错。

出现版本:

1.3.20至1.3.36版本。

修复版本:

1.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)。当设置的起始值超过支持的范围后,会出现精度溢出,从而导致结果不正确。

出现版本:

1.3.20至1.3.35版本。

修复版本:

1.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,当查询同时命中升级前后多个分区时,由于分区子表元数据不一致,导致执行报错。

出现版本:

1.3.20至1.3.35版本。

修复版本:

1.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,从而性能变差。

出现版本:

1.3.20至1.3.34版本。

修复版本:

1.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,从而出现性能退化。

出现版本:

1.3.20至1.3.34版本。

修复版本:

1.3.35及以上版本。

  • 开启JSONB列存后不加LIMIT

  • 建议升级到最新版本。

P0

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

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

出现版本:

1.3.14至1.3.33版本。

修复版本:

1.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过滤,生成了错误的执行计划,导致过滤无效。

出现版本:

1.3.33及以下版本。

修复版本:

1.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码,导致报错。

出现版本:

1.3.33及以下版本。

修复版本:

1.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报错。

出现版本:

1.3.20至1.3.32版本。

修复版本:

1.3.33及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.3.30至1.3.31版本。

修复版本:

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

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

出现版本:

1.3.20至1.3.29版本。

修复版本:

1.3.30及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.27至1.3.28版本。

修复版本:

1.3.29及以上版本。

  • 使用主实例提供查询。

  • 建议升级到新版本。

2022年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.30至1.3.27版本。

修复版本:

1.3.28及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.3.27及以下版本。

修复版本:

1.3.28及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.20至1.3.27版本。

修复版本:

1.3.28及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.3.24至1.3.26版本。

修复版本:

1.3.27及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.3.20至1.3.26版本。

修复版本:

1.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,导致查询报错。

出现版本:

1.3.24及以下版本。

修复版本:

1.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类型转换错误,导致查询报错。

出现版本:

1.3.20至1.3.24版本。

修复版本:

1.3.25及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.20至1.3.24版本。

修复版本:

1.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系统表时,从不同的节点获取数据,导致结果不稳定。

出现版本:

1.3.22至1.3.24版本。

修复版本:

1.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)在推导执行计划时,精度推导错误,从而导致执行报错。

出现版本:

1.3.20至1.3.24版本。

修复版本:

1.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"]),此类型在转执行计划的时候被错误转成某个无意义的数值,导致没有数据命中。

出现版本:

1.3.22至1.3.24版本。

修复版本:

1.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"}}');

出现版本:

1.3.24及以下版本。

修复版本:

1.3.25及以上版本。

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

  • 建议升级到新版本。

    说明

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

P2

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

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

出现版本:

1.3.20至1.3.24版本。

修复版本:

1.3.25及以上版本。

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

    grant SELECT on pg_subscription to "xx";
  • 建议升级到新版本。

P2

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

接入节点(Frontend)对RAM用户解析错误,导致报错。

出现版本:

1.3.23及以下版本。

修复版本:

1.3.24及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.14至1.3.23版本。

修复版本:

1.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类型的精度进行了额外裁剪,导致结果精度错误。

出现版本:

1.3.20至1.3.23版本。

修复版本:

1.3.24及以上版本。

建议升级到新版本。

2022年09月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

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

出现版本:

1.3.14至1.3.22版本。

修复版本:

1.3.23及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.3.14至1.3.22版本。

修复版本:

1.3.23及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.21及以下版本。

修复版本:

1.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类型精度推导错误,导致结果报错。

出现版本:

1.3.20及以下版本。

修复版本:

1.3.21及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.3.20及以下版本。

修复版本:

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

出现版本:

1.3.20及以下版本。

修复版本:

1.3.21及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.3.20及以下版本。

修复版本:

1.3.21及以上版本。

建议升级到新版本。

2022年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.80至1.1.86版本。

修复版本:

1.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,数据因为过期被清理。

出现版本:

1.1.85及以下版本。

修复版本:

1.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,导致查询报错。

出现版本:

1.1.84及以下版本。

修复版本:

1.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账号,否则会没有权限。

出现版本:

1.1.83及以下版本。

修复版本:

1.3.20及以上版本。

P2

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

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

出现版本:

1.1.80及以下版本。

修复版本:

1.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恢复,导致消费失败。

出现版本:

1.3以下版本。

修复版本:

1.3.20及以上版本。

建议升级到新版本。

2022年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.80及以下版本。

修复版本:

1.1.81及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.78及以下版本。

修复版本:

1.1.79及以上版本。

建议升级到新版本。

2022年06月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

Analyze OSS外部表时,出现OOM(Out Of Memory)。

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

出现版本:

1.1.76及以下版本。

修复版本:

1.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)端报错。

出现版本:

1.1.73及以下版本。

修复版本:

1.1.74及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.73及以下版本。

修复版本:

1.1.74及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.70及以下版本。

修复版本:

1.1.71及以上版本。

建议升级到新版本。

2022年05月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.69及以下版本。

修复版本:

1.1.70及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.67及以下版本。

修复版本:

1.1.68及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.64及以下版本。

修复版本:

1.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状态的检查,当增加多列时,状态检查错误,导致增加列失败。

出现版本:

1.1.1至1.1.58版本。

修复版本:

1.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过滤的数据被识别为了非法数据进行转换,导致报错。

出现版本:

1.1.58及以下版本。

修复版本:

1.1.59及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.57及以下版本。

修复版本:

1.1.58及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.55及以下版本。

修复版本:

1.1.56及以上版本。

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

  • 建议升级到新版本。

    说明

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

2022年04月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.54及以下版本。

修复版本:

1.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

出现版本:

1.1.52及以下版本。

修复版本:

1.1.53及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.52及以下版本。

修复版本:

1.1.53及以上版本。

建议升级到新版本。

2022年03月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.50及以下版本。

修复版本:

1.1.51及以上版本。

  • 显式设置user-mapping,详情请参见OSS数据湖加速

  • 建议升级到新版本。

    说明

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

P2

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

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

出现版本:

1.1.47至1.1.50版本。

修复版本:

1.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端口,导致写入报错。

出现版本:

1.1.50及以下版本。

修复版本:

1.1.51及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.49及以下版本。

修复版本:

1.1.50及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.49及以下版本。

修复版本:

1.1.50及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.49及以下版本。

修复版本:

1.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过滤条件丢失,结果出错。

出现版本:

1.1.48及以下版本。

修复版本:

1.1.49及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.47及以下版本。

修复版本:

1.1.48及以上版本。

建议升级到新版本。

2022年02月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.1至1.1.46版本。

修复版本:

1.1.47及以上版本。

  • 关闭数据脱敏。

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.1至1.1.46版本。

修复版本:

1.1.47及以上版本。

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

  • 建议升级到新版本。

    说明

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

P1

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

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

出现版本:

1.1.1至1.1.46版本。

修复版本:

1.1.47及以上版本。

建议升级到新版本。

P2

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

元仓采集信息不全导致。

出现版本:

1.1.1至1.1.46版本。

修复版本:

1.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)生成了错误的执行计划,导致结果出错。

出现版本:

1.1.46及以下版本。

修复版本:

1.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等类型,导致部分非精确类型在执行时报错。

出现版本:

1.1.46及以下版本。

修复版本:

1.1.47及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.46及以下版本。

修复版本:

1.1.47及以上版本。

  • 使用key in max(key)

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.45及以下版本。

修复版本:

1.1.46及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.44及以下版本。

修复版本:

1.1.45及以上版本。

建议升级到新版本

P2

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

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

出现版本:

1.1.44及以下版本。

修复版本:

1.1.45及以上版本。

建议升级到新版本

P1

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

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

出现版本:

1.1.44及以下版本。

修复版本:

1.1.45及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.44及以下版本。

修复版本:

1.1.45及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.43至1.1.44版本。

修复版本:

1.1.45及以上版本。

建议升级到新版本

P0

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

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

出现版本:

0.8及以下版本。

修复版本:

0.9及以上版本。

建议升级到新版本

P1

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

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

出现版本:

1.1.43及以下版本。

修复版本:

1.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)时没有做精度校验,导致查询报错。修复后在新增列时会对精度校验,未指定精度会报错。

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

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

  • 建议升级到新版本。

P0

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

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

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

  • 取消账号的访问权限。

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

  • 不使用行列共存的表

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.42及以下版本。

修复版本:

1.1.43及以上版本。

  • 重启实例。

  • 建议升级到新版本。

2022年01月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2

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

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

出现版本:

1.1.41及以下版本。

修复版本:

1.1.42及以上版本。

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

  • 建议升级到新版本。

    说明

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

P2

分区子表通过attach到分区父表后,查分区表时报错:partition_table_missing

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

出现版本:

1.1.41及以下版本。

修复版本:

1.1.42及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.0至1.1.40及以下版本。

修复版本:

1.1.41及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.0至1.1.40及以下版本。

修复版本:

1.1.41及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.0至1.1.40及以下版本。

修复版本:

1.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 类型),导致执行失败。

出现版本:

1.1.0至1.1.40及以下版本。

修复版本:

1.1.41及以上版本。

建议升级到新版本。

P2

修改分区子表的生命周期(TTL)后出现报错:Invoke StoreMasterClient failed:ERPC_ERROR_CONNECTION_CLOSED

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

出现版本:

1.1.0至1.1.40及以下版本。

修复版本:

1.1.41及以上版本。

  • 暂不修改子表TTL。

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.39及以下版本。

修复版本:

1.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,导致实例报错。

出现版本:

1.1.38及以下版本。

修复版本:

1.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之后的列,而非分区列。分区裁剪只能对分区列生效,导致性能变差。

出现版本:

1.1.38及以下版本。

修复版本:

1.1.39及以上版本。

  • View中不对分区列进行cast

  • 建议升级到新版本。

P2

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

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

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

出现版本:

1.1.36及以下版本。

修复版本:

1.1.37及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.36及以下版本。

修复版本:

1.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。

出现版本:

1.1至1.1.35及版本。

修复版本:

1.1.36及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1至1.1.35及版本。

修复版本:

1.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 ('')生成了错误的执行计划,导致结果不正确。

出现版本:

1.1.35及以下版本。

修复版本:

1.1.36及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.35及以下版本。

修复版本:

1.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字段查询时生成了错误的执行计划,导致查询错误。

出现版本:

1.1.35及以下版本。

修复版本:

1.1.36及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.35及以下版本。

修复版本:

1.1.36及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.35及以下版本。

修复版本:

1.1.36及以上版本。

建议升级到新版本。

P1

Query包含LeadLag函数,同时函数的第三个参数缺省时报错:Column column5 should be non-nullable but the values contain 1 nulls

执行器对于LeadLag函数的输出结果的Nullable推导不正确,导致报错。

出现版本:

1.1.34及以下版本。

修复版本:

1.1.35及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1.35及以下版本。

修复版本:

1.1.36及以上版本。

  • 不使用Roaring Bitmap。

  • 建议升级到新版本。

P1

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

Roaring Bitmap存在内存泄漏。

出现版本:

1.1.34及以下版本。

修复版本:

1.1.35及以上版本。

  • 不使用Roaring Bitmap。

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.33及以下版本。

修复版本:

1.1.34及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.33及以下版本。

修复版本:

1.1.34及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1至1.1.32版本。

修复版本:

1.1.33及以上版本。

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

  • 建议升级到新版本。

P0

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

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

出现版本:

1.1.32及以下版本。

修复版本:

1.1.33及以上版本。

建议升级到新版本。

P1

升级至1.1版本后,多表(十几个表)Join出现OOM异常,且升级前运行正常。

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

出现版本:

1.1至1.1.31版本。

修复版本:

1.1.32及以上版本。

建议升级到新版本。

P2

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

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

出现版本:

1.1至1.1.31版本。

修复版本:

1.1.32及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1至1.1.31版本。

修复版本:

1.1.32及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.30及以下版本。

修复版本:

1.1.31及以上版本。

建议升级到新版本。

P1

使用函数to_charto_dateto_timestamp时报错:time after 2282 not supported

函数to_charto_dateto_timestamp支持的时间范围是1925 ~ 2282年,超出时间范围就会报错。

出现版本:

1.1.30及以下版本。

修复版本:

1.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结果错误,表现为结果比实际少。

出现版本:

1.1.30及以下版本。

修复版本:

1.1.31及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1至1.1.27版本。

修复版本:

1.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失败,导致报错。

出现版本:

1.1.27及以下版本。

修复版本:

1.1.28及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.27及以下版本。

修复版本:

1.1.28及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.27及以下版本。

修复版本:

1.1.28及以上版本。

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

  • 建议升级到新版本。

2021年11月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P2(优化)

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

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

出现版本:

1.1.24及以下版本。

修复版本:

1.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导致内存飙高。

出现版本:

1.1.24及以下版本。

修复版本:

1.1.26及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.24及以下版本。

修复版本:

1.1.26及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.24及以下版本。

修复版本:

1.1.26及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.24及以下版本。

修复版本:

1.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精度不一致的时候,后端计算引擎处理结果不一致导致报错。

出现版本:

1.1.24及以下版本。

修复版本:

1.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用于元数据)。

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

在1.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无法生成计划,从而导致报错。

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

建议升级到新版本。

P0

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

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

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

建议升级到新版本。

P1

报错:Remote seek with parameters is not supported

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

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1至1.1.23版本。

修复版本:

1.1.24及以上版本。

  • 重新新建资源组。

  • 建议升级到新版本。

P2

偶发报错:fail to setremoteost invalid remon ip

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

出现版本:

1.1.23及以下版本。

修复版本:

1.1.24及以上版本。

  • 请重试几次。

  • 建议升级到新版本。

P1

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

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

出现版本:

1.1.22及以下版本。

修复版本:

1.1.23及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.22及以下版本。

修复版本:

1.1.23及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

1.1.22及以下版本。

修复版本:

1.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没有判断导致执行出错。

出现版本:

1.1至1.1.21版本。

修复版本:

1.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信息不存在,导致实例重启。

出现版本:

1.1.21及以下版本。

修复版本:

1.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),小数点保存太多位数导致溢出,从而报错。

出现版本:

1.1.21及以下版本。

修复版本:

1.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上界,从而导致报错。

出现版本:

0.10.19至0.10.42版本。

修复版本:

1.1及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

0.10.41。

修复版本:

0.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集合里面,导致顺序丢失。

出现版本:

0.10.42。

修复版本:

0.10.45及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

0.10.41及以下版本。

修复版本:

0.10.42及以上版本。

  • 不对该表进行操作。

  • 联系值班重启实例。

  • 建议升级到新版本。

P2

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

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

出现版本:

1.1.18及以下版本。

修复版本:

1.1.19及以上版本。

  • 等待一段时间重试。

  • 建议升级到新版本。

2021年08月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P1

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

建表(create table)时,显式指定的Binlog TTL未真正生效,默认为100年。

出现版本:

0.10版本。

修复版本:

1.1版本。

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

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

P1

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

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

出现版本:

0.10.25以下版本。

修复版本:

0.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再落到磁盘,在写入期间去查询,查询列标记长度和真实数据长度未对齐,导致查询失败报错。

出现版本:

0.10.41版本。

修复版本:

0.10.42及以上版本。

建议升级到最新版本。

P1

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

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

  • extract(xxx FROM time)

  • extract(xxx FROM interval)

  • date_part(xx, interval)

出现版本:

0.10.31以下版本。

修复版本:

0.10.32及以上版本。

  • 不使用列表中的函数。

  • 建议升级到最新版本。

P2

提示报错:time before epoch time not supported

SQL中使用了to_charto_dateto_timestamp这些函数的其中一个或多个,且数据有1970年之前的数据,Hologres不支持1970年之前的数据。

出现版本:

0.10及以下版本。

修复版本:

1.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才可以访问这个表。

出现版本:

0.10版本。

修复版本:

1.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。

出现版本:

0.10.40及以下版本。

修复版本:

1.1版本。

建议升级到最新版本。

P2

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

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

出现版本:

0.10.30及以下版本。

修复版本:

0.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有\ + 字符或数字的情况处理不够完善,导致报错。

出现版本:

0.10.38及以下版本。

修复版本:

0.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');

出现版本:

0.10.37及以下版本。

修复版本:

0.10.38及以上版本。

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

  • 建议升级到新版本。

P2

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

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

出现版本:

0.10.35及以下版本。

修复版本:

0.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);

出现版本:

0.10.34及以下版本。

修复版本:

0.10.35及以上版本。

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

  • 建议升级到最新版本。

2021年07月

等级

报错/问题描述

缺陷原因

出现/修复版本

规避建议

P0

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

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

出现版本:

0.10.24及以下版本。

修复版本:

0.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名,导致单个节点异常,从而导致出现写入/查询卡住现象。

出现版本:

0.10.20及以下版本。

修复版本:

0.10.21及以上版本。

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

  • 建议升级到新版本。

P0

报错:cannot acquire lock in time

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

出现版本:

0.9.22及以下版本。

修复版本:

0.9.23及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

0.10.23及以下版本。

修复版本:

0.10.24及以上版本。

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

  • 建议升级到新版本。

P1

在执行extract XXX FROM timestamptz/timestamp时,提示报错:time before epoch time not supported

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

出现版本:

0.10.20及以下版本。

修复版本:

0.10.21及以上版本。

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

  • 建议升级到新版本。

P1

报错:cant determine shard id of shard value

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

出现版本:

0.10.20及以下版本。

修复版本:

0.10.21及以上版本。

建议升级到新版本。

P1

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

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

出现版本:

0.9及以下版本。

修复版本:

0.10已开发限制。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

0.9.22及以下版本。

修复版本:

0.9.23及以上版本。

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

  • 建议升级到新版本。

P1

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

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

出现版本:

0.9.24及以下版本。

修复版本:

0.9.25及以上版本。

  • varchar字段改成TEXT字段。

  • 建议升级到新版本。

P2

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

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

出现版本:

0.10.20及以下版本。

修复版本:

0.10.21及以上版本。

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