Hologres:Notable fixes

Level

Description

Cause

Affected & fixed versions

Workaround

P1

After you modify the number of shard replicas for an instance, the instance briefly restarts. Sample SQL:

--The instance briefly restarts.
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'); 

After you modify the number of shard replicas for an instance, the metadata is not updated. This causes the instance to briefly restart.

Affected:

• Versions 2.1.1 to 2.1.10.

• Version 2.0.33 and earlier.

Fixed:

• Version 2.1.11 and later.

• Version 2.0.34.

Upgrade to the latest version.

P2

After a data import using the `hg_insert_overwrite` stored procedure fails, the temporary table is not cleared.

The `hg_insert_overwrite` procedure creates a temporary table during execution. Because a cleanup mechanism is not implemented, the temporary table remains after the task fails.

Affected:

Version 2.0.19 and earlier.

Fixed:

Version 2.0.30 and later.

• You can manually delete the temporary table.

• Upgrade to the latest version.

P2

Using a fixed plan to write data to a DECIMAL column in Hologres may cause a data error. This error occurs if the data is a negative number and the difference between its least significant decimal place and the destination field's precision is 19 or more. Sample SQL:

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

-- A write error is triggered. This is because the data is a negative number, and the difference between its least significant decimal place and the destination field's precision is 19.
INSERT INTO fixed_plan_decimal VALUES (-1.000000000);

-- The written result is 7922816250.4264337593543950336.
SELECT * FROM fixed_plan_decimal;
 

A data error occurs because the fixed plan ingest endpoint incorrectly handles the precision of the DECIMAL type.

Affected:

Version 2.1.11 and earlier.

Fixed:

Version 2.1.12 and later.

• When you write data, you can explicitly specify the data precision, such as -1.000000000::decimal(38,19).

• Upgrade to the latest version.

P1

After an instance with binary logging enabled is upgraded to V2.1.9, CPU utilization increases significantly.

After an instance with binary logging enabled is upgraded to V2.1.9, binary logging fails to catch errors correctly in some scenarios. This failure prevents the process from exiting normally after an error, which causes excessive logging and high CPU utilization.

Affected:

Versions 2.1.1 to 2.1.9.

Fixed:

Version 2.1.10 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Recommendations

P1

The var_samp function returns an incorrect result for the variance when the input data type is DECIMAL. Sample SQL:

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

-- The result for the DECIMAL type is incorrect.
SELECT var_samp(f1) FROM t1;
-- Returned result
var_samp   
--------------
 0.2382402695

-- The result is correct after the type is converted to INT.
SELECT var_samp(f1::int) FROM t1;
-- Returned result
var_samp     
------------------
 28749.0000000000
 

The var_samp function has a type transform fault when it calculates the variance for the DECIMAL type. This causes an incorrect result.

Affected:

2.0.27 and earlier.

Fixed:

2.0.28 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Workaround

P2

An error occurs when you use the date_part function to retrieve an uppercase field: error: unsupport extract type xxx. The following is a sample SQL statement:

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

The optimizer does not correctly detect the uppercase field in the date_part function. This causes the query to fail.

Affected:

2.0.1 to 2.0.25.

Fixed:

2.0.26 and later.

Upgrade to the latest version.

P2

A query error occurs when you use the && operator to connect arrays: Unexpected expr type in array expr:145. The following is a sample SQL statement:

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

The execution engine for the && operator is Hologres Query Engine (HQE). When the && operator connects arrays, the optimizer incorrectly processes the arrays. This leads to an incorrect execution plan and causes the query to fail.

Affected:

2.0.25 and earlier.

Fixed:

2.0.26 and later.

Upgrade to the latest version.

P2

For a partitioned table, if a WITH statement selects zero partitions, the column alias in the returned result is incorrect. The following is a sample SQL statement:

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

--Query statement that selects 0 partitions
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;

--Incorrect result with the wrong alias 
 v2 | v1 
----+----

--Correct result with the right alias
vb | va 
----+----

For a WITH CTE query on a partitioned table, if the SQL statement selects zero partitions, the query optimizer (QO) optimizes away the nodes for the zero partitions when it generates the execution plan. This causes the returned result to be incorrect and the column alias to be lost.

Affected:

2.0.25 and earlier.

Fixed:

2.0.26 and later.

Upgrade to the latest version.

P2

The CASE WHEN statement uses the DECIMAL type, and the CASE WHEN statement contains a function that is processed by the Parallel Query Engine (PQE), which causes the following error:

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]).

When a CASE WHEN statement contains a DECIMAL type that is processed by a function on PQE, the precision of the DECIMAL is not transformed correctly. This causes a precision mismatch that results in an error.

Affected:

2.0.23 and earlier.

Fixed:

2.0.24 and later.

Upgrade to the latest version.

P2

An error occurs when you import data into a child table if the parent and child tables are in different schemas: Can't find parent table for table name. The following is a sample SQL statement:

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 allows parent and child tables to exist in different schemas. When you run an `INSERT` operation on tables in different schemas, the system does not correctly identify the parent-child relationship. This causes the operation to fail.

Affected:

2.0.23 and earlier.

Fixed:

2.0.24 and later.

Upgrade to the latest version.

P2

For a row-oriented table, if the clustering key and primary key (PK) are different and a time-to-live (TTL) is not explicitly set, duplicate primary keys appear in query results after a bulk load import that uses INSERT ON CONFLICT DO UPDATE. The following is a sample SQL statement:

--Create table statement
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 ;


--Duplicate primary keys appear during query
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

The INSERT ON CONFLICT DO UPDATE operation for row-oriented tables works by marking a record for deletion and then inserting a new one. If the PK and clustering key of a row-oriented table are different, the file marked for deletion is not correctly processed during compaction. This results in duplicate primary keys.

Affected:

2.0.22 and earlier.

Fixed:

2.0.23 and later.

• You can set the PK and clustering key of the row-oriented table to be the same, or change the table to a column-oriented table.

• Upgrade to the latest version.

P2

An error occurs when you use multiple COUNT DISTINCT functions with a GROUP BY clause on a column that is generated by the array_to_string(array_sort(...)) expression: ORCA failed to produce a plan : No plan has been computed for required properties. The following is a sample SQL statement:

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 generates a common table expression (CTE). The array_sort function does not support CTE inlining. This causes an error in the execution plan derivation and makes the SQL statement fail.

Affected:

2.0.22 and earlier.

Fixed:

2.0.23 and later.

Upgrade to the latest version.

P2

After you run DROP SERVER, some queries get stuck.

After DROP SERVER is executed, the replay operation among the FE nodes fails. This leads to version inconsistencies between the nodes, which causes queries to get stuck.

Affected:

1.3.40 to 1.3.51.

Fixed:

1.3.52 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Workaround

P2

When you use a Proxima vector index, an error occurs during data writes if you insert a null vector and do not use a fixed plan: internal error: check condition "and_handle_null" assert failed. The following sample SQL shows an example:

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;

-- Insert a null vector.
INSERT INTO t values (null);
-- ERROR:  internal error: check condition "and_handle_null" assert failed.

In non-fixed plan mode, writing a null vector value causes a system mismatch during the CHECK (array_ndims(vector) operation, which results in an error.

Affected:

2.0.21 and earlier.

Fixed:

2.0.22 and later.

Upgrade to the latest version.

P1

After you enable storage encryption for a MaxCompute project, querying MaxCompute data from a Hologres foreign table occasionally fails with one of the following errors: query next FROM foreign table executor failed, Channel is empty, or internal error: Connect timeout.

In Hologres V2.0.15, a fix for an abnormal key transfer issue during MaxCompute data decryption introduced a multi-threaded memory corruption problem. When a MaxCompute foreign table is in a schema evolution state, this problem can cause the SQE component to occasionally restart because of a coredump. This leads to intermittent errors when the application layer accesses the foreign table.

Affected:

2.0.15 to 2.0.20.

1.3.61 to 1.3.62.

Fixed:

2.0.21 and later.

Upgrade to the latest version.

P2

An error occurs when you use string_agg to process a field that has the NOT NULL property: Column column0 should be non-nullable but the values contain 1 nulls. The following sample SQL shows an example:

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

The output of string_agg can be null. However, the QO infers whether the result is null based on the properties of the processed field. If the field is NOT NULL, the QO infers that the string_agg result cannot be null. This leads to an incorrect result and triggers an error.

Affected:

2.0.20 and earlier.

Fixed:

2.0.21 and later.

Upgrade to the latest version.

P2

If an instance has many table groups and shards (shard count greater than 100), shards can become unevenly distributed because of issues, such as a worker failure. The shards remain unevenly distributed even after you run the Shard rebalancing (Rebalance) command.

If an instance has many table groups and shards (shard count greater than 100), the Rebalance command inaccurately reallocates shards, which causes them to remain unevenly distributed.

Affected:

2.0.20 and earlier.

Fixed:

2.0.21 and later.

Upgrade to the latest version.

P2

When a table field contains 4-byte UTF-8 data, using substring to process the data from the table returns an incorrect result. However, using substring to process the same 4-byte UTF-8 data independently returns the correct result. The following sample SQL shows an example:

-- Returns 3, which is correct.
SELECT length(substring (E'\U0001F345' || '23456789', 1, 3));
-- When using substring on data from a table, the result is incorrect.
create table t (emoji text);
insert into t values (E'\U0001F345' || '23456789');
-- Returns 1, which is incorrect. The expected result is 3.
SELECT length(substring(emoji, 1, 3)) FROM t;

In the current implementation, substring only supports 3-byte UTF-8 data. This causes an incorrect result when substring is used on data from a table.

Affected:

2.0.19 and earlier.

Fixed:

2.0.20 and later.

Upgrade to the latest version.

P2

After you enable binary logging (Binlog) consumption, CPU usage increases significantly.

Because of unreasonable default system parameter settings, high-frequency system logs are generated during Binlog consumption, which causes an increase in CPU usage.

Affected:

2.0.17 to 2.0.19.

Fixed:

2.0.20 and later.

Upgrade to the latest version.

P2

The string_agg or array_agg function returns an incorrect result when an aggregate filter is used. The following sample SQL shows an example:

• DDL and data import:

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

• Query 1:

  SELECT array_agg(x) filter (where x is not null) FROM test group by y;sql-- Expected result: [null][null]-- Actual result, which is incorrect: {null}{null}

• Query 2:

  SELECT array_agg(x) filter (where x is  null) FROM test group by y;-- Expected result: {null,null}{null,null}-- Actual result, which is incorrect: {null,null}{null}

When an aggregate filter is used with string_agg or array_agg, the filter is not processed correctly. This leads to incorrect or unstable filter results.

Affected:

2.0.18 and earlier.

Fixed:

2.0.19 and later.

Upgrade to the latest version.

P2

If the result of an array_agg filter operation on a field with the NOT NULL property contains null, the instance briefly restarts. The following sample SQL shows an example:

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;

When you use array_agg filter, if the field itself is NOT NULL, the query engine (QE) infers that the result is NOT NULL. However, if the actual result contains null, it conflicts with the inferred result, which causes the instance to coredump.

Affected:

2.0.18 and earlier.

Fixed:

2.0.19 and later.

Upgrade to the latest version.

P1

When you use Proxima, setting the min_flush_proxima_row_count parameter to 0 causes the instance to restart.

For the Hologres storage engine (SE), the value of the min_flush_proxima_row_count parameter must be greater than 0. If you set min_flush_proxima_row_count to 0, the SE validation fails, which causes the instance to restart.

Affected:

2.0.18 and earlier.

Fixed:

2.0.19 and later.

Upgrade to the latest version.

P2

After you enable automatic partition creation, an error occurs if you move a table to another schema and then create a new table with the same name in the original schema: ERROR: auto_partitioning.time_unit could only be specified once. The following sample SQL shows an example:

-- Enable automatic partitioning.
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;
-- Change the schema of the table.
alter table test set schema to public;
-- Recreate the table with the same name.
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

After you enable automatic partition creation and then change the schema of the original table, the automatic partitioning configuration is not moved with the table. This causes a configuration conflict and an error when you create a new table with the same name in the original schema.

Affected:

2.0.18 and earlier.

Fixed:

2.0.19 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Workarounds

P2

Using the Concat function with a single column as an argument causes an error: Function concat node must have at least 2 arguments but it only has 1. For example:

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

Older versions do not support using the Concat function with a single column as an argument. This causes the error.

Affected:

2.0.17 and earlier.

Fixed:

2.0.18 and later.

Upgrade to the latest version.

P1

After you enable cold storage for a partitioned table, running an ALTER SCHEMA operation, such as ADD COLUMN, on the parent table causes the child tables to not transform to cold storage as expected. Specific issues might include the following:

• Some child tables remain in the transferring state.

• Child tables that should be transformed to cold storage are not transformed. For example, you set child tables older than 10 days to be cold storage, but some of these tables remain as hot storage.

• Child tables that are already in cold storage are still stored as hot storage when you view their storage information.

In a scenario where cold storage is set for a partitioned table, if you run an ALTER SCHEMA operation on the parent table, the operation also affects the child tables. This causes an inconsistency in the storage properties of the child tables between the FE node and the metadata manager (SM). The child table is marked as cold storage on the FE but as another mode in the SM. This leads to unexpected behavior in the cold storage transformation. You can run the following SQL statement to find the tables with unexpected cold storage behavior:

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;

Affected:

2.0.17 and earlier.

Fixed:

2.0.18 and later.

• You can modify the storage property of the child tables that have been converted to cold storage within a transaction. For example:

  begin;call set_table_property('schema.<cold_child_table_name>', 'storage_mode', 'hot');call set_table_property('schema.<cold_child_table_name>', 'storage_mode', 'cold');commit;

• Upgrade to the latest version.

  Note

  After the upgrade, you must correct the storage properties for the child tables that were in cold storage before the upgrade.

P2

Read-only secondary instances cannot consume Hologres binary logging.

This issue is caused by a change in a default property of the read-only secondary instance.

Affected:

Early versions of 1.3 and 2.0.

Fixed:

1.3.61, 2.0.17, and later versions.

You can use the primary instance to consume Hologres binary logging, or upgrade to the latest version.

P2

When a column is compared with columns of different types using an OR operator, such as col::type = const1::type1 OR col::type = const2::type2, the result is empty or unexpected. For example:

create table t (a date, b timestamp, c text, d int);-- The 'a' column is of the DATE type. After the OR operator, it is converted to the TIMESTAMP type, which causes an unexpected result.SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = timestamp '2023-06-14';-- The types of the fields connected by OR are inconsistent.SELECT * FROM t where a in (timestamp '2023-06-12', timestamp '2023-06-13') or a = '2023-06-14';

When the types of fields connected by an OR operator are inconsistent, the QO does not align the types when it generates the execution plan. This causes the final output to differ from the expected result.

Affected:

1.3.59 and earlier, and

2.0.14 and earlier.

Fixed:

1.3.60 and later, and 2.0.15 and later.

Upgrade to the latest version.

P2

In a primary/secondary instance setup, running HG_MOVE_TABLE_TO_TABLE_GROUP or setting a table to readonly might cause the secondary instance to become unavailable.

The secondary instance has the Lazy Open mechanism enabled. After you perform a resharding operation or manually set readonly to true on the primary instance and then write data again, the shard states of the primary and secondary instances become inconsistent. This causes the secondary instance to become unavailable.

Affected:

1.3.42 to 2.0.16.

Fixed:

2.0.17 and later.

• To perform a resharding operation or set a table to read-only, you can first run the following commands on the secondary instance to disable the Lazy Open mechanism:

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

  After you apply the settings, restart the instance. This new configuration causes a slight increase in memory usage.

Level

Description

Cause

Affected & fixed versions

Workaround

P1

Querying data using the PQE engine returns the following error:

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" }

The PQE process has an intermittent bug that occurs when it processes SQL requests. This bug can cause process leaks. When the number of leaked processes reaches the limit of 512, the instance cannot process any new query requests sent to the PQE process.

Affected:

2.0.1 to 2.0.11.

Fixed in versions:

2.0.12 and later.

Upgrade to the latest version.

P2

An error occurs when a shared cluster reads encrypted data from ODPS:

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

Shared clusters do not support encrypted data.

Affected:

2.0.15 and earlier.

Fixed in versions:

2.0.16 and later.

Upgrade to the latest version.

P2

A backup fails if the source instance contains cold storage tables with frequent write operations.

Frequent writes to cold storage tables trigger continuous data compaction. The backup and recovery feature uses a non-disruptive backup method. The continuous compaction prevents shard versions from aligning. As a result, the backup process cannot obtain the latest state of the shards, which causes the backup to fail.

Affected:

2.0.15 and earlier.

Fixed in versions:

2.0.16 and later.

• You can convert the cold storage tables with frequent writes to hot storage tables, and then create the backup. For more information, see Data Tiered Storage.

• Upgrade to the latest version.

P2

An instance briefly restarts after a PQE SQL query is manually canceled or times out.

PQE SQL queries consume significant resources. When a query is canceled manually or by a system timeout, it may fail to terminate properly. This failure leads to a null pointer error, which causes the instance to coredump.

Affected:

Versions 2.0.12 to 2.0.14.

Fixed:

2.0.15 and later.

Upgrade to the latest version.

P2

A CASE WHEN query that contains the array[] type fails and reports the following error:

Filter has x rows but length of columns is y.

Using a CASE WHEN statement on a field of the array[] type causes data loss from within the array[]. This causes the query to fail.

Affected:

2.0.10 and earlier.

Fixed in versions:

2.0.11 and later.

Upgrade to the latest version.

P2

After you run the DROP operation on a table with binary logging enabled and then restart the instance, the instance storage does not decrease. The storage usage shown by monitoring is greater than the result of the pg_database_size query.

After a DROP operation on a table with binary logging enabled, an instance restart causes the table's binary logging directory to not be properly deleted. As a result, storage usage does not decrease.

Affected:

2.0.12 and earlier.

Fixed in versions:

2.0.13 and later.

Upgrade to the latest version.

P2

If you specify `asc` or `desc` order for a distribution key when you create a table, it causes query errors or brief instance restarts. For example:

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

The distribution key does not support specifying asc/desc order. This causes a replay to fail when the FE executes a DDL statement. This failure results in a coredump or errors when you query or write to the corresponding table.

Affected:

1.3.55 and earlier.

Fixed:

1.3.56 and later.

• Do not specify an asc or desc order when you create a distribution key.

• Upgrade to the latest version to fix the coredump issue. After the upgrade, creating a table with an asc or desc order for its distribution key causes the invalid distribution column: xx:asc error.

Level

Description

Cause

Affected & fixed versions

Workarounds

P2

In SLPM mode, when you use the slpm_alter_view_owner function to create two views with the same name in different schemas, an error occurs: ERROR: more than one row returned by a subquery used as an expression. The following is a sample SQL statement:

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;

In SLPM mode, creating a view across schemas references the pg_class system table. If views with the same name exist in different schemas, the relname column in pg_class contains duplicate values. This causes the subquery to return more than one row, which results in an error.

Affected:

2.0.3 to 2.0.9.

Fixed:

2.0.10 and later.

Upgrade to the latest version.

P2

After you enable cold storage, a read-only secondary instance briefly restarts when it accesses a cold storage table.

The configuration of the read-only secondary instance in the current version is missing the environment variables for cold storage. This causes an error when the read-only secondary instance accesses a cold storage table.

Affected:

1.3.54 and earlier.

Fixed:

1.3.55 and later.

• You can convert the cold storage table to a Standard storage table.

• Upgrade to the latest version.

P2

After you upgrade a Hologres instance to V1.3, you create a Hologres foreign table in MaxCompute. When you use dual signing to access Hologres instances in the China (Shanghai) and US (Virginia) regions, a query error occurs:

ERROR: pooler: xxxx: authentication failed.

After the upgrade, an environment configuration error in the China (Shanghai) and US (Virginia) regions causes the authentication for MaxCompute to access Hologres using dual signing to be missing. This results in an authentication error when MaxCompute queries Hologres.

Affected:

1.3.54 and earlier.

Fixed:

1.3.55 and later.

Upgrade to the latest version.

P2

After you upgrade a Hologres instance to V1.3, the maximum number of connections for a single node is not 128 in the China (Shanghai) and US (Virginia) regions when you run the following command:

show max_connections;

After the upgrade, an environment configuration error in the China (Shanghai) and US (Virginia) regions causes the actual value of the maximum number of connections for a single node to differ from the default value of 128.

Affected:

1.3.54 and earlier.

Fixed:

1.3.55 and later.

Upgrade to the latest version.

P2

After data masking is enabled, an SQL query that uses a CTE and `UNION` on a masked field fails and reports the following error:

The following is an example error message: 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;

After data masking is enabled, `UNION ALL` is not supported for masked fields. When a CTE and `UNION` are used, a null pointer occurs in the outer query. This causes the instance to generate a coredump and the query to fail.

Affected:

1.3.51 and earlier.

Fixed:

1.3.52 and later.

Upgrade to the latest version to resolve the instance coredump. However, `UNION` is not supported for masked fields. The query reports the error UNION is not supported on security item.

P2

After you upgrade Hologres from V1.1 to V1.3, the result of CAST(array AS text) contains an escape character (\). The following is an example:

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;

--Result in the latest V1.3 version
"{"[\"7416461\",\"czzzzz\",\"2023-04-16 23:13:34\"]"}"

--Result in V1.1
"{"["7416461","czzzzz","2023-04-16 23:13:34"]"}"

Hologres versions earlier than V1.3.51 did not fully support the CAST(array AS text) transform and did not add the escape character (\). Starting from V1.3.51, Hologres improved support for CAST(array AS text) to align its behavior with the standard PostgreSQL protocol. The query result now includes the escape character (\), which is different from the results in earlier versions. This change in behavior is expected.

Affected:

1.3.50 and earlier.

Fixed:

1.3.51 and later.

The addition of the escape character (\) to the result is expected behavior.

Level

Description

Cause

Affected & fixed versions

Workaround

P2

Executing an SQL statement that contains a Nested Loop Join returns an error: Schema has 1 fields but 2 are expected. The sample SQL statement is as follows:

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

The output columns of a Nested Loop Join in Hologres include Outer and Inner columns. An extra project is required to specify the output columns. The optimizer in the current version of Hologres removes the extra project. This causes a column mismatch in the table and the query fails.

Affected:

1.3.45 and earlier.

Fixed:

1.3.49 and later.

Upgrade to the latest version.

P2

When you convert data of the TEXT type to the JSON type, data that does not conform to the standard JSON format is also converted. The sample SQL statement is as follows:

create table test1(data text);insert into test1 values('{"a","b"}');SELECT data::json FROM test1;--Incorrect result: {"a","b"}

The correct result should be an error: invalid input syntax for type json" detail: "Expected \":\", but found \",\".".

When you perform a text::json type conversion, ::json is processed as a cast. This causes the QE to use a faulty validation for the JSON data format. As a result, the data is incorrectly converted to the JSON type.

Affected:

1.3.20 to 1.3.46.

Fixed:

1.3.47 and later.

Upgrade to the latest version.

P2

When you use the to_number function, which returns the DECIMAL type, and then convert the result to the STRING type, subsequent calculations produce incorrect results. The sample SQL statement is as follows:

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

In Hologres, when the to_number function converts a value, such as 0.0000000000, to the TEXT type, the value is represented in scientific notation. The QE does not correctly handle scientific notation. This causes incorrect query results.

Affected:

1.3.44 and earlier.

Fixed:

1.3.46 and later.

Upgrade to the latest version.

P2

When you read data from special types of tables, such as MaxCompute Cluster tables and Cfile tables, queries are slower compared to reading data from normal MaxCompute tables.

In the current version, when reading data from MaxCompute Cluster tables and Cfile tables, the Hologres compute engine splits the small files of the foreign table into even smaller files. This increases the number of files processed in a single query, which slows down query performance.

Affected:

1.3.20 to 1.3.40.

Fixed:

1.3.45 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Recommendations

P0

Modifying a table schema, such as the TTL, Bitmap, or Dictionary, causes the instance to restart. The following SQL statement is an example of modifying a table's TTL:

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

If an instance was upgraded from an early version, such as V1.1, some historical schema metadata might be missing. This missing information might be accessed after a flush or compaction operation on the table. The current version does not handle the missing schema information correctly, which triggers an instance coredump.

Affected:

1.3.20 to 1.3.44.

Fixed:

1.3.45 and later.

Upgrade to the latest version.

P2

Using `timestamptz` data from before January 1, 1970 causes the to_char(to_timestamp(hour)) function to return a result that is one hour earlier than the actual time. The following is a sample SQL statement:

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

The result is 01:00:00. The expected result is 02:00:00.

The execution engine incorrectly converts the time precision when it processes timestamps. This causes an incorrect result.

Affected:

1.3.20 to 1.3.43.

Fixed:

1.3.44 and later.

Upgrade to the latest version.

P2

A query fails with the following error if an SQL statement converts a `JSONB` type to a `NUMERIC` type without specifying a precision for `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. The following is a sample SQL statement:

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

When a `JSONB` type is converted to a `NUMERIC` type without a specified precision, the execution plan from the optimizer does not provide a default precision. When the execution engine converts `NUMERIC` to `DECIMAL`, it uses a default precision of 0,0. This causes the query to fail.

Affected:

1.3.20 to 1.3.41.

Fixed:

1.3.42 and later.

• You can specify the precision when you convert the `JSONB` type to the `NUMERIC` type.

• Upgrade to the latest version.

P2

Querying data in an OSS data lake reports the following error: query next FROM foreign table executor failed, Failed to call iterateForeignScan: ArrayIndexOutOfBoundsException.

A memory leak occurs in the Hologres data lake query engine when it reads data from OSS. This causes the query to fail.

Affected:

1.3.20 to 1.3.41.

Fixed:

1.3.42 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Recommendations

P2

When you use UNION ALL on two Decimal fields with inconsistent precision, the query reports an error: NUMERIC precision 65535 must be between 1 and 1000. The following is a sample SQL statement:

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 t1
UNION all
SELECT a / power(10, a), c FROM t2

When the precision of the Decimal fields on both sides of a UNION ALL operation is inconsistent, the QO does not align the precision. This causes the QE to detect the inconsistency during execution and report an error.

Affected:

1.3.20 to 1.3.40.

Fixed:

1.3.41 and later.

Upgrade to the latest version.

P2

Within the same transaction, executing the CALL set_table_property command on an existing partitioned parent table reports an error: SET_TABLE_PROPERTY and CREATE TABLE statement are not in the same transaction for table . The following is a sample SQL statement:

-- If the sample partitioned parent table exists, execute the following SQL statement:
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;

In versions earlier than Hologres V1.3.38, if a partitioned parent table exists, using the set_table_property command to set a property to the same value that the table already has causes the SQL statement to be ignored. In Hologres V1.3.38, the validation for setting properties using set_table_property was enhanced. As a rule, you cannot modify certain properties of existing tables, such as orientation, distribution_key, and clustering_key. If you try to modify them, an error is reported.

Affected:

1.3.38 to 1.3.40.

Fixed:

1.3.41 and later.

Upgrade to the latest version.

P2

The to_date, to_char, and to_timestamp functions report an error when they process data with leading spaces: HGERR_detl Field requires 4 characters, but only 0 could be parsed. The following is a sample SQL statement:

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

When data has leading spaces, the to_date, to_char, and to_timestamp functions handle the spaces incorrectly. This causes the data conversion to fail and the query to report an error.

Affected:

1.3.20 to 1.3.40.

Fixed:

1.3.42 and later.

• You can modify the SQL to handle leading spaces. Example: to_char(year, 'FM9999') .

• Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Recommendations

P2

An error occurs when the rb_build function includes a table name: Not support calling pg udf for type (23, LIST). The following is a sample SQL statement:

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

The rb_build function runs successfully if it is executed without a table name. The following is a sample SQL statement:

SELECT rb_build('{1,2,3}')
--Result:
rb_build
\x3a300000010000000000020010000000010002000300                                

When the rb_build function is executed with a table name, it first performs a calculation and then writes the data to the table. The function is executed in HQE. The current version of HQE does not support bidirectional transformation between arrays and PQE arrays. This causes the execution to fail.

Affected:

V1.3.37 and earlier.

Fixed:

V1.3.38 and later.

Upgrade to the latest version.

P2

An SQL statement contains a LIMIT x OFFSET y clause where y>x. After you run the SQL statement, an incorrect number of results is returned. For example, the following SQL statement should return two rows, but it returns zero rows.

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;

When an execution plan is generated, if the OFFSET value is greater than the LIMIT value, the LIMIT is still pushed down to the operator. However, the OFFSET is not pushed down. This causes incorrect query results.

Affected:

V1.3.20 to V1.3.36.

Fixed:

V1.3.37 and later.

• You can modify the SQL statement. Change the OFFSET value to be less than the LIMIT value.

• Upgrade to the latest version.

P2

When you run the `ANALYZE` operation, the following error is reported: ERROR: store statistic results for table `public.table_name` failed: basic_string::_M_create.

The `ANALYZE` operation fails to correctly parse the fields of the table. This causes the error.

Affected version:

V1.3.36.

Fixed:

V1.3.37 and later.

Upgrade to the latest version.

P2

When you run the CREATE TABLE AS command for a specified schema that is not the public schema, an error is reported that indicates that the table cannot be found. The following is a sample SQL statement:

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 message: error:relation "xxx" does not exist;

After you use the SET search_path TO command to specify a schema, if you do not add a schema prefix to the table name in the CREATE TABLE AS statement, the system still searches for the source table and inserts data in the public schema by default. If the table does not exist in the public schema, an error is reported.

Affected:

V1.3.20 to V1.3.36.

Fixed:

V1.3.37 and later.

• You can specify the schema for the table in the CREATE TABLE AS statement. For example:

  create table as test_schema.test_src_1 SELECT * FROM test_src;

• Upgrade to the latest version.

P2

If you set the starting value for a `bigserial` field to a value outside the `int4` range (–2147483648 to 2147483647), the starting value is incorrect when you query the table data. The following is a sample SQL statement:

create table if not exist test_tb(
  id bigserial not null,
  f1 text,
  primary key (id,f1));
--Insert data into the f1 field.
insert into test_tb(f1) values('1'),('2'),('3');
-- Change the auto-increment start value to 100000000000
alter sequence public.test_tb_id_seq restart with 100000000000
-- Insert two rows for testing.
insert into test_tb(f1) values('6'),('7');
SELECT * FROM test_tb order by id asc;
--Result:
id| f1
------------+----
1 | 1
2 | 2
3 | 3
1128270048 | 6
1128270049 | 7

The current version supports starting values for the `bigserial` type only within the `int4` range (–2147483648 to 2147483647). If you set a starting value that is outside this range, a precision overflow occurs. This leads to incorrect results.

Affected:

V1.3.20 to V1.3.35.

Fixed:

V1.3.36 and later.

Upgrade to the latest version.

P2

After you upgrade a Hologres instance from V1.1 to V1.3, the following error is reported when you query or write data of the `Array` type to a partitioned table: internal error: Datasets has different schema Schema. This error occurs when the SQL statement hits partitions created both before and after the upgrade.

The NOT NULL property is not specified for the `Array` type field of the parent partitioned table. The current version incorrectly handles the nullable property for the `Array` type. Before the upgrade, the property defaults to nullable. After the upgrade, it defaults to NOT NULL for new child tables. An error occurs when a query hits partitions from both before and after the upgrade. This is because the metadata of the partitioned child tables is inconsistent.

Affected:

V1.3.20 to V1.3.35.

Fixed:

V1.3.36 and later.

• You can run an operation to modify the properties of the parent partitioned table. For example:

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

• Upgrade to the latest version.

Level

Description

Cause

Affected & fixed versions

Workarounds

P2

In a partitioned table scenario, if JSONB column store is enabled, queries on the parent table are slow, but queries on child tables are fast. The following is a sample SQL statement:

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;

After JSONB column store is enabled, when a parent table is queried, the optimizer cannot push the query down to the child tables. This causes the entire JSONB column to be queried, which degrades performance.

Affected:

Versions 1.3.20 to 1.3.34.

Fixed:

Version 1.3.35 and later.

• You can query the child tables directly.

• Upgrade to the latest version.

P2

When you use JSONB column store, if a query includes a LIMIT clause, the column store does not take effect and the query is slow.

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

If a LIMIT clause exists, the column store pushdown fails in the execution plan. This causes the entire JSONB column to be queried during computation, which results in performance degradation.

Affected:

Versions 1.3.20 to 1.3.34.

Fixed:

Version 1.3.35 and later.

• Do not include a LIMIT clause after you enable JSONB column store.

• Upgrade to the latest version.

P0

In a scenario where direct read of MC external tables is enabled, if an instance restarts for some reason, such as scaling out compute nodes or an OOM event, the instance service fails to start.

When direct read of MC is enabled, a bug in the system implementation may cause an inconsistency between metadata and data status. This prevents the storage engine from loading data correctly and causes the startup to fail. When this issue is fixed, delete statuses may be lost.

Affected:

Versions 1.3.14 to 1.3.33.

Fixed:

Version 1.3.34 and later.

• Do not enable the direct read feature for MC in earlier versions.

• Upgrade to a later version.

P2

When you query the binary logging (Binlog) of a column-oriented table with a Segment Key set, if the WHERE clause uses the Segment Key as a filter condition, the filter condition is ineffective. The following is a sample SQL statement:

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;

In the example, the value of c_time in the query result is not 1. It is another value.

For a column-oriented table with Binlog and a Segment Key configured, if the WHERE clause uses the Segment Key to filter data, an incorrect execution plan is generated. This makes the filter ineffective.

Affected:

Version 1.3.33 and earlier.

Fixed:

Version 1.3.34 and later.

Upgrade to the latest version.

P2

When you use the #> operator to parse JSONB data, an error is reported: Unicode escape values cannot be used for code point values above 007F when the server encoding is not UTF8. The following is a sample SQL statement to create a table:

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

The #> operator uses the json_extract_path function for parsing. When parsing the JSONB type, it uses the Postgres ASCII code by default, which causes the error.

Affected:

Version 1.3.33 and earlier.

Fixed:

Version 1.3.34 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P2

When you use Java Database Connectivity (JDBC) to consume Hologres binary logging (Binlog) for the first time after creating a database with the SPM permission model, the following error is reported: ERROR: internal error: create table hologres.hg_replication_progress failed.

When you use JDBC to consume Hologres Binlog, the system runs the GRANT SELECT ON TABLE hologres.hg_replication_progress TO PUBLIC; command to allow all users to view the hg_replication_progress table. However, the SPM permission model disables the `GRANT` command. This causes the table creation to fail and an error to be reported when you consume the Binlog.

Affected:

V1.3.20 to V1.3.32.

Fixed:

V1.3.33 and later.

• Switch to the standard PostgreSQL authorization model to grant permissions, and then use the SPM model to consume Binlog. Alternatively, you can use the standard PostgreSQL authorization model to consume Binlog directly.

• Upgrade to the latest version.

P1

After an upgrade to Hologres V1.3.30, the memory usage of the instance increases unexpectedly, even though the queries per second (QPS) and data volume remain unchanged.

Hologres has a result cache by default. When an insert operation on the result cache fails, resources are not released promptly, which causes memory usage to increase.

Affected:

V1.3.30 to V1.3.31.

Fixed:

V1.3.32 and later.

Upgrade to the latest version.

P2

When you nest the jsonb_array_element function within the jsonb_object_field function, the following error is reported: internal error: Only jsonb_object_field and jsonb_object_field_text supported. The following is a sample SQL statement.

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

A logic error in function nesting causes a value mismatch.

Affected:

V1.3.20 to V1.3.29.

Fixed:

V1.3.30 and later.

Upgrade to the latest version.

P2

When you query a table in a read-only secondary instance, duplicate primary keys are found. However, no duplicate primary keys are found when you query the same table in the primary instance.

If you delete data immediately after importing it and the read-only secondary instance fails over due to an upgrade or scale-out, duplicate primary keys in the secondary instance are not cleared promptly. This results in duplicate primary keys.

Affected:

V1.3.27 to V1.3.28.

Fixed:

V1.3.29 and later.

• Use the primary instance for queries.

• Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workarounds

P2

When you create a table and set a nullable field as the Clustering Key or Segment Key, query results are occasionally inconsistent.

For a table with a nullable Clustering Key or Segment Key, the result cache incorrectly caches query results, which leads to inconsistent query results.

Affected:

V1.1.30 to V1.3.27.

Fixed:

V1.3.28 and later.

• Recreate the table and ensure that the field for the Clustering Key or Segment Key is not empty.

• Upgrade to the latest version.

P2

When you use the ST_Collect(col) function, the following error is reported: ERPC_CONNECTION _CLOSED.

The PostGIS function is compatible with PostgreSQL. Hologres uses the native PostgreSQL node tag value for checks. An incorrect check causes the error.

Affected:

V1.3.27 and earlier.

Fixed:

V1.3.28 and later.

Upgrade to the latest version.

P2

When you use the string_agg(text) function, the following error is reported: An I/O error occurred while sending to the backend .

In Hologres, the string_agg function is processed by the execution engine. When no separator is specified for string_agg(text), a null pointer occurs when the execution engine processes the function, which causes a query error.

Affected:

V1.3.20 to V1.3.27.

Fixed:

V1.3.28 and later.

• Modify the SQL statement to explicitly specify a separator for string_agg(text,',').

• Upgrade to the latest version.

P2

When you read data from a MaxCompute foreign table using a WITH statement, the query result is inconsistent with the result from a query that does not use a WITH statement.

When you query a MaxCompute foreign table in a format such as CFile or RANGE TABLE, an issue occurs. If the query contains a WITH clause and the output column order of the WITH clause differs from the table's column order, the Hologres foreign table interface returns results in the wrong order. This leads to inconsistent query results.

Affected:

V1.3.24 to V1.3.26.

Fixed:

V1.3.27 and later.

• Do not use a WITH statement in the query.

• Upgrade to the latest version.

P2

When you query an ARRAY field in a MaxCompute foreign table, the following error is reported: Array length did not match record batch length.

When accessing a MaxCompute table in ORC format, the Hologres foreign table interface handles the length of ARRAY fields inconsistently. This causes the ARRAY data length to exceed the limit and an error to be reported.

Affected:

V1.3.20 to V1.3.26.

Fixed:

V1.3.27 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P2

When you set the Distribution Key to an empty string, the following query error is reported: Failed to get bh reader: internal error CONTEXT. The following is a sample DDL statement:

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

If the Distribution Key is set to an empty string, data cannot be correctly routed to the shard where it resides, which causes a query error.

Affected:

V1.3.24 and earlier.

Fixed:

V1.3.26 and later.

• Recreate the table and set a valid Distribution Key.

• You can upgrade to the latest version.

  Note

  After the upgrade, the Distribution Key still cannot be set to empty. This will cause an error during table creation.

P2

When you query a MaxCompute foreign table, the following error is reported: column with id 0 has type date64[ms] but ReadColumn returns array Array(type=timestamp[ms, tz=UTC].

When Hologres reads a MaxCompute foreign table, the DATETIME type is converted incorrectly, which causes a query error.

Affected:

V1.3.20 to V1.3.24.

Fixed:

V1.3.25 and later.

Upgrade to the latest version.

P2

After a Hologres instance is upgraded to V1.3.20, the following error is reported when you query a MaxCompute foreign table that contains an array field: internal error: IOError: Invalid flatbuffers message.

When you read a MaxCompute foreign table, the read interface version is too old to recognize the array type, which causes a query error.

Affected:

V1.3.20 to V1.3.24.

Fixed:

V1.3.25 and later.

• Temporarily avoid querying array fields.

• Upgrade to the latest version.

P2

When you import a PostgreSQL system table into a Hologres table, the results in the Hologres table change randomly and are unstable. The following is an example:

-- Query result is 22505SELECTcount(1)FROMpg_class c inner join pg_attribute a on c.oid = a.attrelid-- Create an internal tableCREATE TABLE public. tables11 (schemaname name NULL);truncate public. tables11-- Inserted data changes randomlyinsert into public.tables11SELECT'tmp'FROMpg_class c inner join pg_attribute a on c.oid = a.attrelidSELECT count(1) FROM public.tables11

PostgreSQL system tables are native to PostgreSQL. Hologres is a distributed system. The continuous execution of DDL statements causes version inconsistencies among frontend (FE) nodes. When you query a PostgreSQL system table, data is retrieved from different nodes, which leads to unstable results.

Affected:

V1.3.22 to V1.3.24.

Fixed:

V1.3.25 and later.

Upgrade to the latest version.

P2

After a Hologres instance is upgraded to V1.3.20 or later, the following error is reported when you query a case when statement that contains a DECIMAL field: 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.

In a case when statement, the precision of the DECIMAL type is not explicitly converted. The optimizer infers the precision incorrectly when it derives the execution plan, which causes an execution error.

Affected:

V1.3.20 to V1.3.24.

Fixed:

V1.3.24 and later.

Upgrade to the latest version.

P2

When you import a PostgreSQL system view into a user-created Hologres table, the Hologres table contains no data. The following is a sample SQL statement.

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;

The PostgreSQL system view pg_catalog.pg_tables contains a filter condition: c.relkind = ANY (ARRAY['r'::"char", 'p'::"char"]). This type is incorrectly converted to a meaningless value when the execution plan is transformed, which causes no data to be hit.

Affected:

V1.3.22 to V1.3.24.

Fixed:

V1.3.25 and later.

Upgrade to the latest version.

P2

When you perform a Proxima vector query, if you set two Proxima vector indexes for a table, the query performance is worse than when you set only one index. The following is a sample DDL statement for setting indexes.

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

When you set two indexes, the syntax for {} in the DDL statement is incorrect. Each index should correspond to one {}. The FE does not correctly intercept the DDL in this format. This causes the first index to be built successfully and the second index to be discarded, which degrades query performance. The correct syntax is as follows:

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

Affected:

V1.3.24 and earlier.

Fixed:

V1.3.25 and later.

• Recreate the table and use the correct syntax for the DDL statement that sets the indexes.

• We recommend upgrading to a new version.

  Note

  After upgrading to the latest version, this incorrect syntax remains unsupported. However, an error is now reported during table creation.

P2

When a non-Superuser user runs the SELECT hg_dump_script('xxxx') command, the following error is reported: ERROR: permission denied for table pg_subscription.

The hg_dump_script function indirectly calls pg_subscription for logical replication. The authorization for pg_subscription fails, which causes the error.

Affected:

V1.3.20 to V1.3.24.

Fixed:

V1.3.25 and later.

• Use a Superuser account to grant permissions. The following is a sample command.

  grant SELECT on pg_subscription to "xx";

• Upgrade to the latest version.

P2

When a Resource Access Management (RAM) user consumes Hologres Binlog using Flink or writes data to Hologres using DataHub, the following error is reported: NoSuchProject.

The frontend node incorrectly parses the RAM user, which causes the error.

Affected:

V1.3.23 and earlier.

Fixed:

V1.3.24 and later.

Upgrade to the latest version.

P2

After a Hologres instance is upgraded from V1.1 to V1.3, the time taken to query a MaxCompute foreign table increases. When you view the execution plan by running `explain sql`, you find that the row_count in the table statistics is 1000. This indicates that the statistics are not automatically updated.

After the Hologres instance is upgraded to V1.3, Auto Analyze does not detect the schema of the foreign table. This prevents the timely retrieval of the foreign table's statistics.

Affected:

V1.3.14 to V1.3.23.

Fixed:

V1.3.24 and later.

• Manually run the analyze <tablename> command.

• Upgrade to the latest version.

P2

When a query statement's union all clause contains a DECIMAL field, the following error is reported: 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;

When you use union all, the precision of the DECIMAL type is additionally cropped when the execution plan is generated, which results in an incorrect result precision.

Affected:

V1.3.20 to V1.3.23.

Fixed:

V1.3.24 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workarounds

P2

A schema is specified in the JDBC connection string, but the schema does not take effect. The schema remains the public schema. The following is a sample connection string:

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

The FE node does not process the string after the question mark (?) in the connection string. This causes the currentSchema setting to not take effect.

Affected:

V1.3.14 to V1.3.22.

Fixed:

V1.3.23 and later.

Upgrade to the latest version.

P1

After a materialized view is created, an SQL query that hits the materialized view for automatic rewriting causes the instance to restart briefly.

For an SQL query that hits a materialized view for automatic rewriting, the optimizer fails to retrieve the table's metadata when generating the execution plan. This causes instance failures.

Affected:

V1.3.14 to V1.3.22.

Fixed:

V1.3.23 and later.

Upgrade to the latest version.

P2

If you set different IP whitelists for multiple users in a single Hologres instance, those users will be unable to access the instance, even from a whitelisted IP address. The following error is reported: reject ip xxx.

After you set an IP address whitelist for a user, the gateway blocks the user, which means the user is not actually added to the whitelist.

Affected:

V1.3.21 and earlier.

Fixed:

V1.3.22 and later.

• Do not set an IP address whitelist, or change the user policy for the whitelist to ALL. To do this, set the Database Restriction parameter to ALL.

• Upgrade to the latest version.

P2

In a Fixed Plan point query scenario, the following error is reported when you query Decimal data: get result failed: scale should between xxxx. The following is an example:

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;

In a Fixed Plan scenario, the precision of the Decimal type is inferred incorrectly, which causes a result error.

Affected:

V1.3.20 and earlier.

Fixed:

V1.3.21 and later.

Upgrade to the latest version.

P2

After you enable an IP address whitelist, the following error is reported when Flink consumes Hologres Binlog: reject ip 1.xxx.

The interface used by Flink to consume Hologres Binlog is the Hologres real-time data import interface (non-JDBC mode). This interface does not support the IP address whitelist feature.

Affected:

V1.3.20 and earlier.

Fixed:

V1.3.21 and later.

• Do not set an IP address whitelist.

• Upgrade to the latest version.

P2

When you explicitly convert an array type to a string type, the following error is reported: ERROR: Cast FROM LIST to STRING is not supported.. The following is an example:

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 does not currently support explicitly converting an array type to a string type.

Affected:

V1.3.20 and earlier.

Fixed:

V1.3.21 and later.

Upgrade to the latest version.

P1

When you query a MaxCompute foreign table, the query gets stuck. The issue is resolved after you restart the instance.

When Hologres reads MaxCompute metadata, if a primary/secondary switchover occurs in the MaxCompute global meta service, Hologres does not handle the exception correctly. This causes retries to fail and leads to query stuttering.

Affected:

V1.3.20 and earlier.

Fixed:

V1.3.21 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workarounds

P2

When you run an SQL query in JDBC Prepare Statement mode, the following error is reported: cannot push query id when transaction is not start.

In JDBC Prepare Statement mode, a transaction has not yet started when the SQL is executed. This prevents a Query ID from being generated and causes the error.

Affected:

V1.1.80 to V1.1.86.

Fixed:

V1.3.20 and later.

• Change the JDBC connection string to Simple mode: jdbc:postgresql://<host>:<port>/<dbname>?preferQueryMode=simple.

• Upgrade to the latest version.

P2

When you modify the TTL, the TTL value contains a comma (,): CALL set_table_property('wdt_qyb.wdt_qyb_trade', 'time_to_live_in_seconds', '315,360,000');. This causes data to be deleted unexpectedly quickly.

The TTL value with a comma, 315,360,000, is invalid. When the SQL is parsed, the value after the comma is removed by default. This sets the TTL to 315 s, and the data is cleared because it has expired.

Affected:

V1.1.85 and earlier.

Fixed:

V1.3.20 and later.

• Use an INT type for the TTL value and do not use commas.

• We recommend upgrading to the new version.

  Note

  After the upgrade, TTL values that contain a comma are invalid and will cause an error during table creation or TTL modification.

P2

When the Clustering Key and primary key (PK) of a row-oriented table are set differently, the following query error is reported: 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;

If the Clustering Key and PK of a row-oriented table are set differently, the storage engine incorrectly generates identical records, which causes a query error.

Affected:

V1.1.84 and earlier.

Fixed:

V1.3.20 and later.

• Set the same Clustering Key and PK for the row-oriented table.

• Upgrade to the latest version.

P2

When a non-Superuser account consumes Hologres Binlog using JDBC, the following error is reported when running the call hg_create_logical_replication_slot('hg_replication_slot_1', 'hgoutput', 'hg_publication_test_1'); command: permission denied for table hg_replication_slot_properties.

A Superuser account is required to consume Hologres Binlog using JDBC. Otherwise, you will not have the required permissions.

Affected:

V1.1.83 and earlier.

Fixed:

V1.3.20 and later.

• Use a Superuser account.

• Upgrade to the latest version and grant certain permissions to the non-Superuser account. For more information, see Consume Hologres Binlog using JDBC.

P2

When you view slow query logs, some logs are missing. However, monitoring information shows latency and QPS.

Different queries within the same transaction have the same Query ID. The metadata warehouse collects and deduplicates the queries, retaining only one query and losing the others.

Affected:

V1.1.80 and earlier.

Fixed:

V1.3.20 and later.

Upgrade to the latest version.

P2

When you consume Hologres Binlog, the following error is reported: com.alibaba.hologres.org.postgresql.util.PSQLException: ERROR: relation "hologres.hg_replication_slot_properties" does not exist.

The FE node of the instance was restarted for some reason. After the node recovered, the Hologres Binlog extension was not restored, which causes consumption to fail.

Affected:

Versions earlier than V1.3.

Fixed:

V1.3.20 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P2

After a hot upgrade, the following error is reported when you query a table: File(fn: xxx) real size != size in meta: 0 != yyyy.

The instance undergoes a hot upgrade. During the hot upgrade, the table has an offline BulkLoad write. During the offline write, the data undergoes compaction. This causes metadata compatibility issues and an error to be reported.

Affected:

V1.1.80 and earlier.

Fixed:

V1.1.81 and later.

• Pause offline writes to the table during the instance's hot upgrade, or perform a normal cold upgrade.

• Upgrade to the latest version.

P2

When you write back to different partitions of the same MaxCompute table concurrently, the following error is reported: ERROR:commit uploder failedErrorMessage=Operation failed due to concurrent upload/insert operationson the same table.

Different MaxCompute partitions belong to the same table. During write-back, the write-back interface shares the same table lock when it runs commit upload session, which causes a lock conflict error.

Affected:

V1.1.78 and earlier.

Fixed:

V1.1.79 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workarounds

P2

An out-of-memory (OOM) error occurs when you analyze an OSS foreign table.

When you run Analyze on an OSS foreign table, the OSS row count interface samples many rows by default (over 30,000 rows), which causes an OOM error.

Affected:

V1.1.76 and earlier.

Fixed:

V1.1.77 and later.

Upgrade to the latest version.

P2

For an SQL query that contains an in clause, if the constant type in the in clause is inconsistent with the actual type of the column, the following error is reported: internal error: Invalid filter value type int32 for column type int16.

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

When the data type of the constant specified by the in operator is different from the original column type, the optimizer does not perform a cast type conversion on the constant. This causes an error at the execution engine side.

Affected:

V1.1.73 and earlier.

Fixed:

V1.1.74 and later.

• Ensure that the constant type in the in clause is consistent with the column type.

• Upgrade to the latest version.

P2

When you create an OSS foreign table by selecting only some fields, the following error is reported: Open ORC file failed for schema mismatch.

When you create a foreign table by selecting some OSS fields, the DPI engine has limited support for some foreign tables. You can select only all fields.

Affected:

V1.1.73 and earlier.

Fixed:

V1.1.74 and later.

• Select all fields to create the foreign table.

• Upgrade to the latest version.

P2

After you delete data from a certain range (such as a partition) and then immediately run an insert command on the same table, the write speed slows down.

After you delete a range or a continuous set of values, compaction is not yet complete. When you run the insert command, it first queries for identical records in that time period and stops only when it encounters the first undeleted record. If there are many continuously deleted records near the queried key, it takes a long time to traverse these records, which slows down the write speed of the insert command.

Affected:

V1.1.70 and earlier.

Fixed:

V1.1.71 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Recommendations

P2

When you query a MaxCompute table, the following error is reported: Timestamp overflow detected while converting timestampFROM orc VectorBatch to arrow.

The MaxCompute table contains a TIMESTAMP type. After writing with Tunnel, the TIMESTAMP precision becomes nanoseconds. Hologres does not currently support nanosecond precision for TIMESTAMP, which causes the error.

Affected:

V1.1.69 and earlier.

Fixed:

V1.1.70 and later.

• Change the TIMESTAMP type of the MaxCompute table to DATETIME.

• Upgrade to the latest version.

P2

When you query OSS Parquet data, the results from each count statement are inconsistent, even though the OSS data has not changed.

When Hologres reads an OSS Parquet file, the interface version is old. This causes null values to appear randomly in non-null data, leading to incorrect query results.

Affected:

V1.1.67 and earlier.

Fixed:

V1.1.68 and later.

Upgrade to the latest version.

P2

When you write back data to MaxCompute using SQL in Hologres, the following error is reported: Blocks not match, server:xx client yy.

When you write back to MaxCompute, the default timeout is 300 s. This causes empty blocks to be generated, which leads to the error.

Affected:

V1.1.64 and earlier.

Fixed:

V1.1.65 and later.

• You can modify the timeout by running the following command.

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

  Changing the timeout to 600s makes it less likely to generate empty blocks.

• Upgrade to the latest version.

P2

In Hologres V1.1, when you add multiple columns to a MaxCompute foreign table, the following error is reported: not support alter table with multi commands. The following is a sample SQL statement.

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

Hologres V1.1 added a status check for the add column operation on foreign tables. When you add multiple columns, the status check is incorrect. This causes the add column operation to fail.

Affected:

V1.1.1 to V1.1.58.

Fixed:

V1.1.59 and later.

• Add one column at a time, or use the IMPORT FOREIGN SCHEMA syntax to refresh the foreign table.

• Upgrade to the latest version.

P1

When you use the to_date function with a where filter condition, the following error is reported: invalid value \"\" for \"YYYY\" HGERR_detl Field requires 4 characters, but only 0 could be parsed. The following is a sample query SQL statement.

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

When you use the to_date function with a where filter condition, the data filtered by the where clause is identified as invalid data for conversion, which causes the error.

Affected:

V1.1.58 and earlier.

Fixed:

V1.1.59 and later.

Upgrade to the latest version.

P2

When you concurrently read an encrypted MaxCompute table, the following error is reported: failed to load row group data FROM file pangu.

When you concurrently read an encrypted MaxCompute table, the reader concurrently parses the encrypted object, which causes a decryption error.

Affected:

V1.1.57 and earlier.

Fixed:

V1.1.58 and later.

Upgrade to the latest version.

P2

When you perform a modulo (%) calculation on a NUMERIC or DECIMAL field and push it down to the execution engine for execution, the calculation result is incorrect.

The execution engine does not support modulo operations for NUMERIC and DECIMAL types, but it does not perform a type check. This leads to an incorrect result.

Affected:

V1.1.55 and earlier.

Fixed:

V1.1.56 and later.

• Do not perform modulo calculations on NUMERIC and DECIMAL fields.

• We recommend upgrading to the new version.

  Note

  Modulo operations on NUMERIC and DECIMAL fields remain unsupported after the upgrade and will return an error.

Level

Error/Problem description

Cause

Affected/Fixed

Recommendations

P2

When you subscribe to Hologres Binlog using JDBC, and then run the pgreplicationstream.start() JDBC consumer Binlog job and simultaneously run drop table xx; on the database side to delete the corresponding table, the instance briefly restarts.

Deleting a table while subscribing to its Binlog causes the table to not exist at the time of subscription. However, subscribing to Binlog requires retrieving the table's table_properties. This leads to a null pointer and causes the instance to restart.

Affected:

V1.1.54 and earlier.

Fixed:

V1.1.55 and later.

• Do not delete tables while subscribing to Hologres Binlog.

• We recommend upgrading to the new version.

  Note

  After a Hologres instance is upgraded, deleting a table that is subscribed to binary logging causes the consuming client to receive an error that the table does not exist.

P2

After a child partition table is detached from its parent table and then attached to the same parent table, the attach operation fails.

A child partition table created with the CREATE TABLE <table_name> PARTITION OF <parent_table> command does not inherit the parent table's Table Group property. When the child partition table is detached and then attached, a check reveals that the child table's Table Group property is inconsistent with the parent table's. This causes the attach operation to fail.

Affected:

V1.1.52 and earlier.

Fixed:

V1.1.53 and later.

Upgrade to the latest version.

P2

When you use Grouping sets and multiple Count Distinct to query a partitioned table, the query result is incorrect.

When you use Grouping sets and multiple Count Distinct to query a partitioned table, the optimizer does not perform partition pruning. This causes the partition filter condition to not be hit, resulting in an incorrect result.

Affected:

V1.1.52 and earlier.

Fixed:

V1.1.53 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workarounds

P2

When you query an OSS foreign table using Data Lake Formation (DLF), the following error is reported: failed to import foreign schema. After you create a user-mapping, the query runs normally.

If no user-mapping is set, the authorization interface passes incorrect permissions, which causes a query error.

Affected:

V1.1.50 and earlier.

Fixed:

V1.1.51 and later.

• Explicitly set a user-mapping. For more information, see Accelerate queries on data in OSS.

• We recommend upgrading to the new version.

  Note

  After the upgrade, you no longer need to explicitly create a user-mapping to access the data.

P2

In PrepareStatement mode, the following error is reported when you query SQL: unrecognized node type: 0, or the Hologres instance briefly restarts.

In PrepareStatement mode, you can generate a Plan cache for repeatedly executed SQL statements to reduce overhead on the client side. In the current version, the Plan cache for SQL is not obtained in a timely manner in PrepareStatement mode, which causes a query error.

Affected:

V1.1.47 to V1.1.50.

Fixed:

V1.1.51 and later.

• Use the jdbc:postgresql://<host>:<port>/<dbname>?preferQueryMode=simple command to change the JDBC connection string to Simple mode.

• Upgrade to the latest version.

P1

When you write to Hologres in Blink or Flink RPC mode, the following error is reported: failed to create channel into server xxx, connection refused to rpc proxy endpoint.

When you write to Hologres in Blink or Flink RPC mode, the interface does not return the Rpcproxy port, which causes a write error.

Affected:

V1.1.50 and earlier.

Fixed:

V1.1.51 and later.

• Switch the Flink job to JDBC write mode. For more information, see fully managed Flink.

• Upgrade to the latest version.

P2

When you run a Join SQL command that contains union all, the following error is reported: internal error: 0 shard end shard value: xxx doesn\'t .

A JOIN SQL statement that contains union all is derived incorrectly when the execution plan is generated, which causes the error.

Affected:

V1.1.49 and earlier.

Fixed:

V1.1.50 and later.

Upgrade to the latest version.

P2

When you use the json_array_elements function and the SQL statement contains a Join command, the following error is reported: Duplicate keys detected when building hash table.

The execution engine (QE) builds a hash table when it executes the Join operator. However, when it actually reads data, it does not properly filter the data processed by json_array_elements. This causes duplicate data to be read and an error to be reported.

Affected:

V1.1.49 and earlier.

Fixed:

V1.1.50 and later.

Upgrade to the latest version.

P2

When you run a Join SQL statement, the following error is reported: Explicit remote seek FROM a source is not supported.

When the execution plan generated by a Join SQL statement (viewed by running explain sql) is a Nested Loop Join, the execution engine incorrectly retrieves the Nested Loop Join-related execution plan. This causes an execution error.

Affected:

V1.1.49 and earlier.

Fixed:

V1.1.50 and later.

Upgrade to the latest version.

P2

When an SQL filter condition contains not in, the query result still contains data filtered by not in. The following is an example.

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

When the optimizer generates the execution plan, it handles not in incorrectly and generates a wrong execution plan. This causes the not in filter condition to be lost and results in an error.

Affected:

V1.1.48 and earlier.

Fixed:

V1.1.49 and later.

Upgrade to the latest version.

P2

In the SLPM permission model, when you modify a schema name by running the CALL slpm_rename_schema ( old_name, new_name ) command, the following error is reported: UPDATE is not supported.

When you modify a schema in the SLPM permission model, the permission interface makes an incorrect judgment, which causes an execution error.

Affected:

V1.1.47 and earlier.

Fixed:

V1.1.48 and later.

Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P2

In SPM or SLPM mode, after you enable data masking, Auto Analyze or Analyze fails.

The backend uses the table owner to run Auto Analyze. However, in SPM or SLPM mode, the table owner is a Developer who does not have logon permissions. When sampling masked columns, it goes through the execution engine, which causes Auto Analyze or Analyze to fail.

Affected:

V1.1.1 to V1.1.46.

Fixed:

V1.1.47 and later.

• Disable data masking.

• Upgrade to the latest version.

P1

When you analyze a foreign table, if the foreign table has too many partitions (usually in a multi-level partition scenario), an error is reported that the partition limit is exceeded (greater than 512 partitions). This causes Analyze to fail.

During analysis, the foreign table partitions are not pruned accordingly, which causes Analyze to fail.

Affected:

V1.1.1 to V1.1.46.

Fixed:

V1.1.47 and later.

• If the number of foreign table partitions is within 1024, you can first increase the foreign table partition limit and then run Analyze.

• We recommend that you upgrade to a newer version.

  Note

  After an upgrade, the Analyze operation processes a maximum of 512 foreign table partitions by default. To process more partitions, you can increase the partition limit for the Analyze operation. For more information, see Optimize the query performance of MaxCompute foreign tables.

P1

When you run the explain analyze SQL command, the result for partitions SELECTed is 0, which does not match the actual number of hit partitions.

When the execution plan is generated, the check for partitions SELECTed is incorrect, which causes the result to be 0.

Affected:

V1.1.1 to V1.1.46.

Fixed:

V1.1.47 and later.

Upgrade to the latest version.

P2

When you view slow query logs, information such as the number of rows read (read_rows) and the number of rows returned (result_rows) cannot be displayed.

This is caused by incomplete information collection by the metadata warehouse.

Affected:

V1.1.1 to V1.1.46.

Fixed:

V1.1.47 and later.

We recommend upgrading to a new version.

P2

When you use JDBC PrepareStatement mode, if you insert or SELECT multiple values and run it several times (more than 3), the results show misplaced rows and columns. However, if you insert or SELECT one value at a time over multiple executions, the results are correct. For example: an SQL statement contains 32 values for a single write, and this is done 4 times, with the order of the 32 rows in the values changing randomly each time. In contrast, if an SQL statement contains only one value and is written as 32 separate SQL statements, the result is correct.

In PrepareStatement mode, when you insert or SELECT multiple values multiple times, the optimizer generates an incorrect execution plan, which leads to an incorrect result.

Affected:

V1.1.46 and earlier.

Fixed:

V1.1.47 and later.

• If the query meets the characteristics of a Fixed Plan, you can enable Fixed Plan to accelerate SQL execution.

• Change the PrepareStatement mode to Simple mode.

• Upgrade to the latest version.

P2

When you run a non-Join SQL statement (such as one containing count distinct), the following error is reported: error: Hash32 shard function does not support decimal or fixed binary type.

Non-Join SQL statements may also use a Shard Function to generate an execution plan. However, the Shard Function does not currently support types such as NUMERIC. This causes an error when some non-exact types are executed.

Affected:

V1.1.46 and earlier.

Fixed:

V1.1.47 and later.

Upgrade to the latest version.

P1

When you use key = max(key), the result is not as expected and always returns only one row. When you use key in max(key), the result is as expected.

When the optimizer generates the execution plan, it converts key = max(key) to order by id asc limit 1. This type of query always returns only one row, which leads to an unexpected result.

Affected:

V1.1.46 and earlier.

Fixed:

V1.1.47 and later.

• Use key in max(key).

• Upgrade to the latest version.

P2

If a DDL from a non-PostgreSQL source (such as JDBC) has an SQL code comment, for example: create table ttxwsx1(i int); -- comments -- xxxxx, after successful execution, writing or querying gets stuck.

A comment at the end of a DDL command causes the final semicolon on the same line to lose its function as a command separator. This causes the new command to be appended after the comment and become invalid, making the SQL illegal. This leads to a Replay failure between nodes, causing writes or queries to get stuck.

Affected:

V1.1.45 and earlier.

Fixed:

V1.1.46 and later.

• Delete the comment at the end of the DDL statement.

• Upgrade to the latest version.

P1

When you query a row-oriented table using a primary key point query, there is a chance that some row-oriented data cannot be queried.

When a row-oriented table performs background file compaction, there is a bug in handling concurrent scenarios. This causes some manifest files to be located incorrectly, resulting in some row-oriented data not being found.

Affected:

V1.1.44 and earlier.

Fixed:

V1.1.45 and later.

Upgrade to the latest version

P2

After a Hologres instance is upgraded to V1.1, when you query a MaxCompute foreign table with multiple partition levels (usually 3 levels), and the SQL filter condition contains or, the query is slower than in V0.10 (previously it took only a few seconds) or an OOM error occurs.

In Hologres V1.1, in multi-level partition filtering, the optimizer cannot recognize the operator generated by the or condition. This causes the generated filter to be empty, meaning no filtering is done. This scans all partitions, which slows down the query or causes an OOM error.

Affected:

V1.1.44 and earlier.

Fixed:

V1.1.45 and later.

Upgrade to the latest version

P1

When CPU usage is not high, memory remains at a high level for a long time. Monitoring shows that the QPS is relatively high (several hundred or more), but only a few dozen connections are used. This means a single connection is executing SQL at a rate of several hundred QPS.

When an SQL statement is executed, the optimizer retrieves the table's statistics. If a single connection executes SQL at a rate of several hundred QPS and the connection is not closed for a long time, a leak occurs when retrieving the statistics. This causes high memory usage.

Affected:

V1.1.44 and earlier.

Fixed:

V1.1.45 and later.

• You can resolve the issue by adding the set hg_experimental_always_show_execution_statistics=off; parameter.

• Upgrade to the latest version.

P2

An SQL statement contains a not like xxx% condition, but the query result still shows data that should have been filtered by not like.

When the optimizer generates the execution plan, the pre-processing rule for like-related functions is incorrect. It performs an incorrect rewrite, which leads to an incorrect result.

Affected:

V1.1.44 and earlier.

Fixed:

V1.1.45 and later.

• When an SQL statement with `like` causes an error, you can resolve it by adding the hg_experimental_remove_redundant_cmp=off; parameter.

• Upgrade to the latest version.

P1

When you log on with an STS account, the following error is reported: Cloud authentication failed. You have checked that the account and password are correct.

The Identity verification interface incorrectly judges the status of the STS account, which causes the error.

Affected:

V1.1.43 to V1.1.44.

Fixed:

V1.1.45 and later.

Upgrade to the latest version

P0

After the application side completes a data write, the engine side's data write process crashes. There is a probability of data loss, and users find data missing when they query.

In the normal process, when a user writes data, a response is returned to the upper-level call only after the Write Ahead Log (WAL) is written to disk. This ensures data persistence and consistency. However, if the disk writing process times out and triggers a system retry, the data is first written to the memory cache part and a response is returned to the upper-level call. If the memory cache process crashes at this point, the application layer returns success, but the data is actually lost in the data storage layer.

Affected:

V0.8 and earlier.

Fixed:

V0.9 and later.

Upgrade to the latest version

P1

When the instance writes and queries data, it fails and reports the following error: ERROR: Invoke StoreMasterClient failed:ERPC_ERROR_CONNECTION_CLOSED.

After the error occurs, query retries from the business side combined with backend FE node retries lead to a very high request volume. The Store Master (metadata management) cannot process them in time and reports an error.

Affected:

V1.1.43 and earlier.

Fixed:

V1.1.44 and later.

• You can use the set optimizer_join_order=query command to temporarily bypass the issue.

• Upgrade to the latest version.

P2

You add a column of type DECIMAL without specifying precision, such as alter table add column c0 decimal;. The query runs successfully, but when you query the new column, the following error is reported: Schema fields[] has type decimal(x,y) but decimal(x1, y1) is expected..

Currently, adding a DECIMAL column without specifying precision is not supported. However, when you add a column (Add Column), no precision check is performed, which causes a query error. After the fix, a precision check is performed when you add a column. An error is reported if no precision is specified.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

• Specify the precision when you add a column with a DECIMAL field.

• Upgrade to the latest version.

P0

After an AccessKey is disabled, you can still use the disabled AccessKey to access a Hologres instance.

The AccessKey interface incorrectly calls the status of a disabled AccessKey. This causes the disabled AccessKey to be used as a normal AccessKey.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

• Revoke the account's access permissions.

• Upgrade to the latest version.

P2

When you create a table with a Default field and use the copy command, the instance restarts.

The copy feature does not support creating a table with a Default value. This causes an OOM error and restarts the instance.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

Upgrade to the latest version.

P2

When you run an INNER JOIN query with a foreign table join, an error is reported that a certain column cannot be found, such as: ERROR: column "id" does not exist, even though this column is not in the SQL statement.

When the optimizer generates the execution plan, its derivation of equivalent expressions is incorrect. Columns that are not in the output are also included in the derivation of equivalent expressions, which causes the error.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

Upgrade to the latest version.

P1

Using a table with both row and column stores, with a complex Nested Loop Join, causes the instance to restart and then quickly recover.

When the optimizer detects a table with both row and column stores, it does not generate a correct execution plan. This causes an error and triggers an instance restart.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

• Do not use tables with both row and column stores.

• Upgrade to the latest version.

P1

After a complex import job with a multi-table (such as 6 tables) join is manually canceled, the CPU usage remains at 100% for several hours and does not end. Running drop table also gets stuck.

For a relatively complex query, the execution plan includes a Hash Join operator that involves a large volume of data. The backend deadlocks, causing the job to continue running in the backend even after being canceled.

Affected:

V1.1.42 and earlier.

Fixed:

V1.1.43 and later.

• Restart the instance.

• Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P2

When data is written from DataHub to a Hologres partitioned table, and a child partition table is not created in advance, the Hologres instance restarts.

When DataHub writes to a Hologres partitioned table, the write interface does not perform a partition check, which causes the instance to Coredump.

Affected:

V1.1.41 and earlier.

Fixed:

V1.1.42 and later.

• Create a child partition table in Hologres before you write data.

• You can upgrade to a new version.

  Note

  For partitioned tables, you must create child partitioned tables after an upgrade before writing data.

P2

After a child partition table is attached to a parent partition table, the following error is reported when you query the partitioned table: partition_table_missing.

The table creation properties of the child partition table are inconsistent with the parent partition table (such as not null constraints, PK settings, and Clustering Key settings). When you attach, the properties are not checked, which causes a query error.

Affected:

V1.1.41 and earlier.

Fixed:

V1.1.42 and later.

• When you create a child partition table, the schema and properties of the child table must be consistent with the parent partition table to which it will be attached.

• Upgrade to the latest version.

P1

When you use JDBC PreparedStatement mode, if the where command in the SQL statement contains a "<" or ">" filter condition, the instance restarts after execution.

When you use JDBC PreparedStatement mode, the "<" or ">" filter condition in the where clause is converted to an INTERVAL when the execution plan is generated. A null pointer is encountered during the conversion, which causes an SQL error and restarts the instance.

Affected:

V1.1.0 to V1.1.40 and earlier.

Fixed:

V1.1.41 and later.

Upgrade to the latest version.

P1

When you use JDBC PreparedStatement mode, if the IN condition exceeds 100 items, there is a probability that the result is incorrect or not as expected.

When you use JDBC PreparedStatement mode, if the IN condition exceeds 100 items, the execution plan generation incorrectly deletes the IN condition. This leads to an incorrect data result.

Affected:

V1.1.0 to V1.1.40 and earlier.

Fixed:

V1.1.41 and later.

Upgrade to the latest version.

P2

When you query a table with both row and column stores using an IN condition, the following error is reported: An I/O error occurred while sending to the backend.. No error is reported when you use a row-oriented table.

When the field type in the IN condition is TEXT and a Bitmap is set for that field, an incorrect execution plan is generated for the table with both row and column stores, which causes the error.

Affected:

V1.1.0 to V1.1.40 and earlier.

Fixed:

V1.1.41 and later.

• Use a row-oriented table.

• Upgrade to the latest version.

P2

When you run an SQL statement where the where condition connects in and = with and, the following error is reported: ERROR: serialized_error_msg is null. Sample SQL:

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

The backend incorrectly judges the data types of the in and = clauses on both sides of the and operator. For example, if `a = 1` is an int type, `a in (1,2,3)` is an array type. This causes the execution to fail.

Affected:

V1.1.0 to V1.1.40 and earlier.

Fixed:

V1.1.41 and later.

Upgrade to the latest version.

P2

After you modify the lifecycle (TTL) of a child partition table, the following error is reported: Invoke StoreMasterClient failed:ERPC_ERROR_CONNECTION_CLOSED.

When you modify the TTL of a child table, the Store Manager (SM) metadata manager makes an error when checking for schema changes, which causes an SQL error.

Affected:

V1.1.0 to V1.1.40 and earlier.

Fixed:

V1.1.41 and later.

• Do not modify the child table's TTL for now.

• Upgrade to the latest version.

P2

When you use the DROP statement to delete a table, the following error is reported: invalid table id. When you retry, the following error is reported: SE object lock failed .

An instance has multiple frontend nodes. When an SQL statement is executed, it is first run on one node and then replayed on other nodes. When a node cannot maintain metadata consistency with other nodes due to version or other reasons, it retries. When you concurrently run drop table, it triggers a node failover. The table lock is not released during the retry, which causes the error.

Affected:

V1.1.39 and earlier.

Fixed:

V1.1.40 and later.

• Run DDL statements such as drop table sequentially.

• Upgrade to the latest version.

P1

After you enable the Auto Analyze feature, the instance reports the following error without a significant increase in QPS: database is not accepting commands to avoid wraparound data loss in database.

After you enable the Auto Analyze feature, the system table of the frontend node does not promptly run auto vacuum. This causes the background to continuously submit SQL statements with transactions, which leads to an instance error.

Affected:

V1.1.38 and earlier.

Fixed:

V1.1.39 and later.

Upgrade to the latest version.

P2

You create a view based on a partitioned table and perform a cast on the partition key column. This prevents the use of static partition pruning, which leads to scanning all partitions and degrades performance. The following is a sample SQL statement:

--Create a viewcreate view test_partition_table_view asSELECTtest_partition_table.ds::text as dsFROMtest_partition_table;--Query sqlSELECT * FROM test_partition_table_view where ds='20211116';

After being encapsulated in a view, the filter condition in the optimizer is based on the column after the cast, not the partition key column. Partition pruning can only be applied to the partition key column. This degrades performance.

Affected:

V1.1.38 and earlier.

Fixed:

V1.1.39 and later.

• Do not perform a cast on the partition key column in the view.

• Upgrade to the latest version.

P2

• When the date is a Sunday, running the to_char(xxx, 'Day') function causes the instance to restart.

• When the date is a Sunday, running the to_char(xxx, 'D') function produces an incorrect result.

When the date is a Sunday, the underlying execution logic of the to_char() function is toDayOfWeek(), which returns a value of 7. This causes an array-index out of bounds error, which restarts the Hologres instance or produces an incorrect result.

Affected:

V1.1.36 and earlier.

Fixed:

V1.1.37 and later.

Upgrade to the latest version.

P1

After you enable data masking for an instance, if a subquery contains a CTE function, the instance briefly experiences a connection error or an I/O error.

When recursively calling to process a CTE function, data masking is not handled correctly, which causes the Hologres instance to restart.

Affected:

V1.1.36 and earlier.

Fixed:

V1.1.37 and later.

• Disable data masking.

• Upgrade to the latest version.

Level

Error/Problem description

Cause

Affected/Fixed

Workaround

P0

Setting a dictionary index for a TEXT field causes the instance to restart briefly. An example SQL statement is as follows:

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

, where a is a TEXT field.

By default, Hologres sets a dictionary for TEXT fields using the auto property. If you manually specify a dictionary for a TEXT field, the property changes to on. This causes the file state to become inconsistent, which prevents compaction and triggers a coredump.

Affected:

1.1 to 1.1.35.

Fixed:

1.1.36 and later.

• When you manually set the dictionary, set the property to auto: call set_table_property('tbl', 'dictionary_encoding_columns', 'a:auto');.

• Upgrade to the latest version.

P2

When you view slow query logs, information, such as the number of rows read (read_rows) and the number of rows returned (result_rows), is not displayed.

The information is not displayed because the metadata warehouse collects incomplete information.

Affected:

1.1 to 1.1.35.

Fixed:

1.1.36 and later.

Upgrade to the latest version. Before you run the SQL statement to view slow queries, add one of the following commands.

• set hg_experimental_force_sync_collect_execution_statistics = on;

• alter database <dbname> set hg_experimental_force_sync_collect_execution_statistics = on;

P1

The result is incorrect if the WHERE clause of an SQL statement contains case when xx in ('').

Hologres builds a bitmap for TEXT types by default. If the column is nullable, the backend generates an incorrect execution plan for case when xx in (''), which causes an incorrect result.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

Upgrade to the latest version.

P1

The following error is reported: Cannot reserve capacity larger than 2^31 - 1 for binary\n .

Hologres builds a dictionary encoding for TEXT columns by default. If an inserted field is too large (a single field exceeds 2 GB), the resulting dictionary becomes too large, which causes queries to fail.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

Upgrade to the latest version.

P1

When you query binary logs, an SQL statement that contains binary logging fields cannot retrieve data from a primary key (PK) field, whereas an SQL statement without binary logging fields can. In the following sample queries, `a` is the PK field of the test table.

--SQL with binary logging
SELECT hg_binlog_lsn, hg_binlog_event_type, hg_binlog_timestamp_us FROM test where a = '723295948321120659';
--SQL without binary logging
SELECT * FROM test where a = '723295948321120659';

The backend optimizer generates an incorrect execution plan for queries that are based on a primary key field. This causes the query to fail.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

Upgrade to the latest version.

P2

When an instance is at full CPU load, you cannot query information, such as active queries and active connections, in HoloWeb.

When the CPU is at full load, system tables such as pg_stat_activity are subject to resource limits. This causes these queries to fail.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

Upgrade to the latest version.

P1

Using an empty ANY array causes the Hologres instance to restart.

The backend incorrectly handles empty ANY arrays, which causes the instance to coredump.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

Upgrade to the latest version.

P1

If a query contains the Lead or Lag function and the third parameter of the function is omitted, the following error is reported: Column column5 should be non-nullable but the values contain 1 nulls.

The executor incorrectly infers the nullability of the output from the Lead and Lag functions, which results in an error.

Affected:

1.1.34 and earlier.

Fixed:

1.1.35 and later.

Upgrade to the latest version.

P2

When Flink writes data that contains a RoaringBitmap field to Hologres, the write speed is very slow.

The write path for data that contains a RoaringBitmap field is not optimized on the backend, which causes poor write performance.

Affected:

1.1.35 and earlier.

Fixed:

1.1.36 and later.

• Avoid using Roaring Bitmap.

• Upgrade to the latest version.

P1

When you use Roaring Bitmap, the following error is reported: An I/O error occurred while sending to the backend. Additionally, memory usage is high when CPU utilization is low.

The Roaring Bitmap feature has a memory leak.

Affected:

1.1.34 and earlier.

Fixed:

1.1.35 and later.

• Avoid using Roaring Bitmap.

• Upgrade to the latest version.

P1

If an SQL statement contains an order by clause, the following error is reported: PlStmt Translation: Attribute number 4 not found in project list.

The order by clause generates a sort operator. The optimizer incorrectly pushes down an operator when generating the execution plan. This prevents the execution plan from being generated and results in an error.

Affected:

1.1.33 and earlier.

Fixed:

1.1.34 and later.

Upgrade to the latest version.

P1

When you run a query that uses Proxima, the following error is reported: HGERR_code XX000 HGERR_msge internal error: record batches is empty.

The backend reads the file state of Proxima incorrectly, which causes an error.

Affected:

1.1.33 and earlier.

Fixed:

1.1.34 and later.

Upgrade to the latest version.

P2

After you upgrade an instance to version 1.1 or restart an instance of version 1.1 for an upgrade or downgrade, the first query runs slowly. Viewing the execution plan shows inaccurate statistics. Running the query again corrects the statistics and restores performance.

After an instance is upgraded and restarted, the first query fails to retrieve the correct version of statistics. This leads to inaccurate statistics and poor performance.

Affected:

1.1 to 1.1.32.

Fixed:

1.1.33 and later.

• You can run the query multiple times to correct the statistics and restore performance.

• Upgrade to the latest version.

P0

Querying a table while running the drop/truncate command causes the instance to restart.

If a drop/truncate operation occurs on a table between the end of a query and data deconstruction, the instance coredumps and then restarts.

Affected:

1.1.32 and earlier.

Fixed:

1.1.33 and later.

Upgrade to the latest version.

P1

After an upgrade to version 1.1, a join of multiple tables (more than 10) causes an out-of-memory (OOM) error. This operation ran normally before the upgrade.

The optimizer overestimates the number of rows in the tables. This causes the executor to encounter an OOM error during the initialization phase, which prevents the next calculation step from running.

Affected:

1.1 to 1.1.31.

Fixed:

1.1.32 and later.

Upgrade to the latest version.

P2

In a serving point query scenario, latency increases because of client-side batching.

Each worker node has only one point query write node. When all requests are sent to the write node, batching is likely to occur. The current batching limit is too high. This leads to a long wait time for batch accumulation and causes high latency for point queries.

Affected:

1.1 to 1.1.31.

Fixed:

1.1.32 and later.

Upgrade to the latest version.

P1

For a table with storage encryption, a query with a limit offset clause returns results. However, if an order by clause is also included, no results are returned.

For a table with storage encryption, if the configuration specified in the documentation is not followed correctly, an incorrect version is generated. This causes data loss in the MemTable and prevents the query from returning results.

Affected:

1.1 to 1.1.31.

Fixed:

1.1.32 and later.

Upgrade to the latest version.

P1

When you run the Truncate command, an error is reported indicating that the table is not found if the table name contains uppercase letters. For example, running #truncate "Abc"; reports the following error: ERROR: relation "abc" does not exist.

The current logic for handling case sensitivity in the Truncate command is incorrect.