Hologres:Notable fixes

Severity level

Description

Root cause

Affected version

Fixed version

Workaround

P0

Flushing data on a logical partitioned table with partial primary key updates may cause the instance to restart.

A defect in how logical partitioned tables handle primary key update scenarios during flush operations.

V3.1.1

V3.2.29, V3.1.43

Upgrade to a fixed version.

P0

Data writes fail with the error Partition count [65535] in memtable has exceed the limit [65535], followed by a worker restart.

A defect in the memtable partition count validation fails to include partitions from the current write batch, causing the worker to terminate unexpectedly.

V4.0.1

V4.1.21, V4.2.2, V4.0.37

Severity level

Description

Root cause

Affected version

Fixed version

Workaround

P1

Running Rebuild on a table with Binlog enabled may cause the frontend node to hang, making the instance unavailable.

A defect in how Rebuild handles Binlog-enabled tables causes lock contention, which can hang the frontend node.

V4.1.1 to V4.1.20

V4.1.21

• Upgrade to a fixed version.

• Disable the GUC parameter set hg_experimental_rebuild_try_to_using_dynamic_table_mode=off before running Rebuild.

P2

Specifying multiple options in the connection string causes connection failures or incorrect parameter values. For example, setting options to -c statement_timeout=1000 -c search_path=public results in the error: Connect to FE failed, invalid value for parameter "statement_timeout": "1000-csearch_path=public"

The gateway module incorrectly strips whitespace when parsing the options field, causing multiple parameters to be merged into a single malformed value.

• V2.0.18 to V2.0.35

• V2.1.1 to V2.1.15

• V2.0.36

• V2.1.16

• Upgrade to a fixed version.

• Avoid specifying more than one option in the connection options string.

Severity level

Description

Root cause

Affected version

Fixed version

Workaround

P2

When you use Data Masking V2 to query a VIEW that contains a masked table, you may incorrectly receive a permission denied for schema xxx or permission denied for table xxx error message.

The data masking feature incorrectly handles permissions.

• V4.0.1 to V4.0.27

• V4.1.1 to V4.1.12

• V4.0.28

• V4.1.13

Upgrade to a fixed version.

P1

When you execute a DML statement on a table that has a global secondary index (Global Index), an error is reported if the execution plan uses the Shard Prune operator: Transaction xxxxxxxxxxxxx has no snapshot of table xxxxx index 1.

The global secondary index feature does not yet support the Shard Prune operator.

V4.0.1

To be fixed

• To resolve a query error, disable the GUC parameter hg_experimental_enable_shard_pruning.

• Upgrade to the fixed version when it is released.

Severity

Description

Root cause

Affected versions

Fixed versions

Workaround

P1

Using the phrase search mode of a full-text inverted index can produce incorrect search results if the slop parameter exceeds 255.

The matching logic for full-text inverted indexes is flawed when the slop value is greater than 255.

V4.0.1

V4.1.9

• Upgrade to the latest version.

• Avoid setting the slop parameter to a value greater than 255.

P2

A dynamic table refresh fails in incremental refresh mode if a Volatile function precedes an aggregate function and is not in the last column. The error is:

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

The distribution key list is passed to the inner query, but it corresponds to the final output columns and cannot be mapped to the columns in the inner query.

V3.1

• V4.1.8

• V4.0.24

• Use full mode, or place the Volatile function after the distribution key.

• Upgrade to the latest version.

P2

When loading a table group into a virtual warehouse, the FE (Frontend) might not retrieve complete shard location information from the SE (Storage Engine), causing FixedFE write operations to fail for approximately 1 second.

In the function DDLReadService::DoGetTableGroupShards, break was used instead of continue when ShardInfos was empty, which caused incomplete data retrieval.

V1.1

• V4.1.7

• V4.0.24

• Upgrade to the latest version.

P2

Batching an array column with a variable-length data type that exceeds 64 MB reports the following error: Copy overflow with offset xx, length xx, and array length xx.

A mutable array reserves space for only one row, but the appended array contains more than one row. When a text column exceeds 64 MB, the builder size is reserved for only one row without considering the minimum required size.

V4.0

• V4.1.6

• V4.0.21

• Workaround: Run alter database xxx set hg_experimental_enable_batch_accumulator_v2=off;.

• Upgrade to the latest version.

P2

When a user runs an SQL statement, the Alibaba Cloud account name is not automatically converted to an ID, for example, in GRANT USAGE ON SCHEMA public TO "ALIYUN$a".

is_initdb is incorrectly treated as true because extern bool is_initdb; is not declared.

• V2.2

• V3.0

• V3.1

• V3.2

• V4.0

V3.0.53

• Use account IDs instead of account names to perform operations.

• Upgrade to the latest version.

P2

During batch copy processing, full shared memory can cause an ERROR: Parse data from copy encountered internal error or a coredump. The stack trace contains holo_copy or CopyReadLineText.

In batch copy mode, client data is batched by row count and written to shared memory. If a single row is large (approximately 600 MB per batch), concurrent writes from multiple connections can exhaust the shared memory. This can cause subsequent writes to fail or the process to crash because the read-side reads invalid values due to an overflow.

V1.1

• V4.1.5

• V4.0.21

• V3.2.31

• Workaround: Use streaming copy writes or decrease the value of the hg_experimental_query_batch_size parameter (default: 8192). For example, alter user xx set hg_experimental_query_batch_size = 512;.

• Upgrade to the latest version.

P2

When reading array columns from Parquet files, an error occurs due to page index skipping. This issue may be triggered when the page index is enabled (default), an SQL query reads array columns, and a predicate pushdown to the Parquet reader filters any page of any column.

A compatibility issue exists between the page index skipping logic and array column reading. When predicate pushdown causes a page to be skipped, the read state of the array column is not correctly synchronized.

V3.1

• V4.1.5

• V4.0.19

• V3.2.29

• V3.1.43

• Workaround: Disable the page index: set hg_experimental_enable_external_parquet_use_page_index = off;.

• Upgrade to the latest version.

P2

Fixed an issue in Fixed plan mode where an INSERT ON CONFLICT statement produced an incorrect result if the WHERE clause was a constant. For example, when you executed insert into a values(0,1) on conflict(id) do update set id = excluded.id, name = excluded.name where 1 = 0;, no rows were written even if the ID did not conflict.

When the WHERE condition is a constant expression, the condition is not rewritten correctly, which prevents data that meets the condition from being written.

V4.0

• V4.1.6

• V4.0.24

• Use the INSERT OR IGNORE syntax and avoid using constant conditions in ON CONFLICT expressions.

• Upgrade to the latest version.

P2

The Parquet reader cannot process empty row groups. An error is reported when reading a row group that contains 0 rows. In Hologres V3.1 and later, this may cause a coredump, and the stack trace contains hologram::spi::parquet::RowRange.

The reader assumes that a row group contains data and is not empty. When processing an empty row group, the end-of-file (EOF) marker returned by the data page parser is ignored, which incorrectly triggers the error handling logic.

V3.0

• V4.1.4

• V4.0.19

• V3.2.29

• Workaround: Execute the query using hiveqe and set the GUC parameter to set hg_experimental_force_access_dlf_paimon_via_hiveqe = on; or set hg_experimental_force_access_dlf_iceberg_via_hiveqe = on; or hg_experimental_enable_access_dlf_via_fse = off;.

• Upgrade to the latest version.

P0

Submitting an empty file during a bulkload operation causes the flush operation to fail. When a file with a size of 0 is submitted, the subsequent flush operation fails because it cannot open the file to read its metadata.

When a bulkload operation triggers a deletion compaction, all rows in the selected file are marked for deletion, which generates an empty file.

V3.1

• V4.1.2

• V4.0.18

• V3.2.29

• V3.1.43

• Workaround: Set the GUC parameter and re-import the table: set hg_serverless_computing_run_compaction_before_commit_bulk_load = off;.

• Upgrade to the latest version.

P2

A write operation fails for a Fixed plan if the global secondary index contains a boolean type. An error is reported when you create a global index and insert data: ERROR: XX000: internal error: unexpected error, failed to write, detail: Unsupported type in fixed dispatcher.

The fixed dispatcher does not support writing Boolean values to a global secondary index.

V4.0.0

• V4.0.16

• V4.1.2

• Upgrade to the latest version.

P2

A Holo FDW cross-instance query fails. After you upgrade to version 4.0, the following error is reported when you query a foreign table: Fetch table group shards failed on meta proxy:Loading cached shard location value for table group[...] failed.

The FDW fails to load the cached shard location value.

V4.0.6

• V4.0.15

• V4.1.1

• Upgrade to the latest version.

P2

Writing data from a data-masked table to a destination table with an auto-incrementing column causes unexpected behavior. In Hologres V4.0 and earlier, this operation may cause a coredump or abnormal error behavior.

The code assumes a one-to-one mapping between parsetree->targetList and rte_insert->insertedCols. This assumption is invalid when the destination table contains an auto-incrementing column because parsetree->targetList includes both the auto-incrementing and user-specified columns, while rte_insert->insertedCols includes only the user-specified columns.

V3.1

• V3.2.26

• V4.0.14

• V3.1.42

• Avoid using auto-incrementing columns.

• Upgrade to the latest version.

P2

The Array Ref interface is not thread-safe and can cause a coredump. Starting from Hologres V2.2, in the shuffle logic for worker-level shuffle and QE v2, multi-threaded access to array->type can cause a coredump, and the type field of the array becomes an invalid value.

Although the ArrayRef type-retrieval interface is marked as const, the mutable keyword allows the type_ member variable to be modified. Concurrent access to type by multiple threads can corrupt the control block of type_, which leads to thread-safety issues.

V3.1

• V4.1.6

• V4.0.21

• V3.2.31

• V3.1.45

• Temporary workaround: Disable worker-level shuffle and QE v2.set hg_experimental_enable_worker_level_connection = off; set hg_experimental_enable_qe_v2 = off;.

• Upgrade to the latest version.

P2

An error occurs when you add a column to an existing Dynamic table by using the alter definition statement. If the base table is a physical partitioned table and the Dynamic Table (DT) is a logical partitioned table, executing the alter definition statement on the DT reports one of the following errors: ERROR: New definition is not supported in incremental mode: Multiple partitions of table XXX is selected or ERROR: New definition is not supported in incremental mode: No partitions of table XXX is selected.

During the creation process, a GUC parameter was set to ignore the query optimizer's partition number check, but this logic was not synchronized in the ALTER DEFINITION process.

V3.1

• V3.1.40

• V3.2.24

• V4.0.12

• V4.0.13

• Workaround: Set the GUC parameter by executing set hg_experimental_check_selected_partition_table_number_for_dynamic_table = off;, and then execute alter definition.

• Upgrade to the latest version.

P2

A duplicate primary key error is reported when you create an External Dynamic table. This occurs when the select query for the External DT joins or unions multiple identical tables. As a result, the generated base table list contains duplicates, which causes an error when data is inserted into the system table: ERROR: duplicate key value violates unique constraint "pg_holo_external_dynamic_table_dependencies_name_index".

This issue affects both dynamic tables and external dynamic tables. The system table for a dynamic table does not have a primary key, so inserting duplicate records does not cause an error. However, the system table for an external dynamic table has a primary key constraint, which prohibits duplicate records.

V4.0

V4.0.13

• Upgrade to the latest version.

P2

An aggregate query on data of the char(n) type fails. After you enable AQE, executing the select col1, max(col2) from t1 group by col1 statement returns the following error: hos_exception: Internal error: HGERR_code XX000 ExecuteQuery failed, last errmsg: syntax error at or near "4294967291".

In ORCA, the type_modifier field was not inferred for aggregate results of the char type. This caused the type_modifier of the aggregate result to be set to -5 (which is 4294967291 as an unsigned integer). When AQE was enabled, it attempted to create a char(4294967291) field, which exceeded the length limit and caused an error.

V3.1

• V3.1.39

• V3.2.24

• V4.0.12

• V4.0.13

• Workaround: Disable AQE: alter database xxx set hg_experimental_enable_adaptive_execution = off;.

• Upgrade to the latest version.

P2

Snapshot SQL execution fails when a view contains a subquery without an alias. If a view's SELECT statement uses the subquery alias optional feature to create a subquery without an alias, executing the snapshot SQL generated by hg_dump_script returns an error: unnamed_subquery does not exist.

When PostgreSQL infers the view definition SQL from the view rule, it does not enforce an alias for the subquery. If a user's view has a subquery without an alias, the inferred view definition SQL also lacks an alias, but the target list specifies one, which causes an SQL parsing failure.

V4.0

• V4.1.6

• V4.0.12

• Recreate such views by using CREATE OR REPLACE and provide an alias for each subquery.

• Upgrade to the latest version.

P1

Duplicate records appear after grouping a Paimon Deletion Vector (DV) table by primary key. This occurs when a Parquet file contains a page with a FIXED_LEN_BYTE_ARRAY physical format, a decimal logical format, and plain encoding. If a record batch being read from that column crosses a page boundary, the data after the boundary within that batch is incorrectly placed at the start of the record batch.

The Parquet decoder did not apply an offset when placing data, which caused incorrect data positioning when a record batch crossed a page boundary.

V3.1.0

• V3.1.39

• V3.2.23

• V3.2.24

• V4.0.12

• Workaround: Execute select hg_admin_command('set_global_flag', 'enable_create_decimal_array_v2 = true');.

• Upgrade to the latest version.

P2

After MaxCompute table queries are switched to the Common Table access path, Auto Analyze cannot obtain the latest last modified time for the table, and Out of Memory (OOM) errors can occur. After an upgrade to Hologres V3.0.51, OOM errors may persist when querying foreign tables by using the Common Table path. In a three-level model for a MaxCompute table, the schema name in the response from the Common Table access path becomes default instead of Hologres' project name. This causes Auto Analyze to fail in the batch retrieval of the foreign table's last modified timestamp, and no change information is collected.

The Common Table access path and holo_native are not aligned in their handling of the three-level model. For the fetcher->GetTables interface in a three-level model, holo_native returns the project_name as the schema_name, but the Common Table access path returns default as the schema_name. This causes a data backfill failure.

V3.0

• V3.0.52

• V3.1.39

• V3.2.23

• V3.2.24

• Manually run the ANALYZE command.

• Upgrade to the latest version.

P2

When Hologres queries MC data by using CommonTable, a slow memory leak occurs in the oct_get_partition_names interface. The issue occurs after an upgrade from Hologres V3.1.22 to V3.1.30, causing a continuous and slow increase in memory usage over the long term. It is triggered by high-frequency queries on MC partitioned tables when CommonTable is enabled.

The oct_get_partition_names interface has a slow memory leak, causing a continuous increase in memory usage over time.

V3.0

• V3.0.51

• V3.1.36

• V3.2.18

• V4.0.7

• The memory leak is slow. When holo_worker memory is high, you can restart the pods with high memory to recover. If there are many pods, you can restart the instance.

• Upgrade to the latest version.

P1

On the probe side of a hash join, a runtime filter generated from the first child of a UNION ALL is pushed down to the second child, causing data loss in the query result.

During the mapping and pushdown process to the second child of the UNION ALL operation, the runtime filter from the first child was incorrectly merged, leading to an erroneous pushdown.

V3.1

• V3.1.39

• V3.2.23

• V3.2.24

• V4.0.12

• Workaround: Set the GUC parameter: alter database set hg_experimental_enable_runtime_filter_push_thru_union_all=off;.

• Upgrade to the latest version.

P2

Dynamic tables that have been renamed or whose schemas have been altered cannot be automatically refreshed after an upgrade to Hologres V4.0.7 or a later version. The following error message is reported: ExecuteQuery failed, last errmsg: Can not find dynamic table properties of XXX or relation "XXX" does not exist.

A dynamic table needs to periodically fetch the latest properties from the FE (Frontend) in the driver. When the code was moved from the table driver to the driver master, the logic for synchronizing the latest table and schema names was omitted. This causes refreshes to fail after an upgrade because they use the initial creation name.

V4.0.7

• V4.0.10

• V4.0.13

• Upgrade to the latest version.

P2

A CREATE TABLE AS SELECT (CTAS) statement shows degraded performance because of certain optimization steps during the createstmt phase of query optimization.

Some unnecessary optimization steps in the query optimization phase for CTAS statements negatively impacted performance.

V4.0

• V4.0.10

• V4.0.13

• Upgrade to the latest version.

P1

Using the ANY_VALUE aggregate function on an incrementally refreshed dynamic table produces incorrect results. Multiple values are returned when querying the dynamic table, even though the base table field has only one value.

In FinalizeStateRows, the result_array was incorrectly generated inside a loop. This bug was not cherry-picked to the V3.2 release branch.

V3.2

V3.2.24

• Workaround: Replace the function with a MIN or MAX function, such as select id, sum(col1), min(col2) from t1 group by id.

• Upgrade to the latest version.

P2

The number of out of memory (OOM) errors increases when you query foreign tables after switching from the normal link to the Common Table link. The following error is reported: ERROR: internal error: common table memory pool out of memory.

Permission changes in the Common Table access path during Auto Analyze collection prevent the system from obtaining the table's last modified time. This prevents Auto Analyze from being triggered, leading to outdated statistics and OOM errors.

• V3.0.42

• V3.1

• V3.2

• V4.0

• V4.0.9

• V3.1.38

• V3.2.21

• V3.0.51

• V3.2.24

• Manually run the ANALYZE command.

• Upgrade to the latest version.

P2

An error occurs in serverless mode when refreshing a dynamic table while multiple row-level transactions are open.

A patch moved the check for a non-existent table group to the FE (Frontend) but did not account for the serverless scenario. This issue is triggered when a serverless DML statement that cannot be auto-routed is run on a follower virtual warehouse.

V4.0

• V4.0.9

• V4.0.13

• Use DML auto-routing by granting permissions to the leader virtual warehouse, or connect to the leader virtual warehouse to run SQL statements or create the dynamic table.

• Upgrade to the latest version.

P2

A query results in an Out of Memory (OOM) error.

The execution class (EC) priority of the shuffle operation was lowered, preventing it from getting enough time slices when CPU usage was high. This slowed data retrieval on the build side, delayed runtime filter construction, and caused the probe side to read excessive data, reducing filtering efficiency.

Versions later than V4.0.x

• V4.0.10

• V4.0.13

• Workaround: Set the following GUC parameters: hg_experimental_enable_qe_v2 = on, hg_experimental_runtime_filter_wait_time_ms = 10000, and hg_experimental_wait_for_all_runtime_filters = on.

• Upgrade to the latest version.

P1

The client_addr field is empty in some login audit logs.

When the gateway reports login audit logs, it makes an additional call to getpeername to retrieve the client IP address. If the client connection has already been abnormally disconnected, the IP address cannot be obtained.

All versions that support login audit logs

V4.0.13

• Upgrade to the latest version.

P2

An error is reported when you use preparestmt to execute a query that contains a clustering key: ERROR: XX000: Dispatch query failed: internal error: DataType::STRING column range conjuncts should use string literal or parameter ref.

mask_md5 is a clustering key. During the prepared statement phase, the expression mask_md5 in (md5($1),md5($2)) cannot be constant-folded. This causes the extracted clustering filter to contain the md5 function, and the backend reports an error because it cannot parse this filter.

V1.1

• V3.1.37

• V3.2.20

• V4.0.8

• V3.2.24

• Workaround: Do not use preparestmt or change mask_md5 in (md5($1),md5($2)) to mask_md5 = md5($1) or mask_md5 = md5($2).

• Upgrade to the latest version.

P2

In rare cases, a coredump occurs when a query with a LIMIT clause is run or manually canceled early, which causes the query to fail and the worker to restart.

The SplitFactory::Close function released resources but did not use its own ExecutionContext. This caused resources to be released before other functions had finished, which triggered a coredump.

V3.2.4

• V4.0.7

• V3.2.19

• V3.2.24

• V4.0.13

• To work around this, set the GUC parameter: alter role all set hg_experimental_enable_qe_v2 = off;.

• Upgrade to the latest version.

P2

After a TableGroup is unloaded, Holoweb login fails and the metadata warehouse reports the error ERROR: 42704: Table group[bizp.bizp_tg_default] is not found in warehouse bdmp_api_warehoue. Gateway metrics show a high number of new connection requests and high latency, and a large number of new fixed fe connections are created in a short period. When consuming the binlog at startup, lock acquisition takes a long time, and high concurrency can cause insert operations to get stuck.

When an unload occurs, new requests such as binlog or fixed plan requests on the old virtual warehouse retry in bhclient for 27.5 seconds. Binlog consumption on the FixedFE synchronously calls this method when connecting to the EC. When a retry occurs, it blocks the connection to the EC, which causes new FixedFE connection creation to get stuck and leads to a connection buildup.

V3.2

V4.0.8

• Stop the binlog consumption task and modify the Flink job to use the correct virtual warehouse. Alternatively, log on to HoloWeb and load the unloaded table group to the target virtual warehouse. If HoloWeb is inaccessible, contact an FE (Frontend) developer to restart the gateway from the backend.

• Upgrade to the latest version.

P2

In Hologres V3.1, after you enable auto refresh for a Dynamic Table, the container memory continuously increases when observed over a 7-day period. The FE memory increases while the holo worker memory remains stable. The memory also continuously increases when you repeatedly execute hg_generate_query_options_for_dynamic_table.

The UDF hg_generate_query_options_for_dynamic_table has a memory leak. The UDF instantiates a HoloQmDispatcher object. Although the object is managed by a shared_ptr, the DispatcherManager stores it in a map that is keyed by query_id. The query_id created by the code is a separate ID and is not the query_id of the query that the UDF executes. When a query is complete, RemoveDispatcher(query_id) should be called to remove the dispatcher. However, this step is missing in the code. Because the lifecycle of the DispatcherManager is bound to the connection (conn) process, the dispatcher objects accumulate over time.

V3.1.0

• V4.0.0

• V3.1.26

• V3.2.8

• Workaround: Find and terminate long-lived connections in pg_stat_activity, or register a cron job to automatically clean up connections that are older than 1 hour: SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE length(query) > 0 AND pid != pg_backend_pid() AND backend_type = 'client backend' AND state = 'idle' AND application_name = 'DynamicTableTableDriver' AND current_timestamp - backend_start > '1 hour';

• Upgrade to the latest version.

P2

In an instance, two workers have higher memory usage than other workers, with no shard skew. Monitoring shows a significant difference in FE (Frontend) memory. Queries from the time memory started increasing reveal a long-running connection that has run a large number of DDL statements (query_count > 1000).

The DDL execution process has a memory leak. The memory for a QueryDesc object is released when the query-level MemoryContext is released at the end of the query. However, UtilityStmt (broadly DDL) allocates memory in a long-lived MemoryContext. This memory is not released when the query-level MemoryContext is released, which causes a memory leak.

All versions

• V3.1.22

• V3.2.5

• V3.2.24

• Workaround: Close the long-lived connections that have memory leaks to free up memory. You can use the following SQL query to identify these connections:SELECT pid, session_id, count(*) as query_count, max(query_start) FROM meta_warehouse.query_info WHERE query_start > now() - '1 hour'::interval AND command_tag NOT IN ('INSERT','SELECT','DELETE','UPDATE') GROUP BY 1,2 ORDER BY 3 DESC LIMIT 20;

• Upgrade to the latest version.

Severity

Description

Cause

Affected versions

Fixed versions

Workaround

P1

An instance may briefly restart when you create a table with a name that contains spaces, special characters, and mixed-case letters.

The instance coredumps because it reads an incorrect state when it retrieves table properties from a system table.

• V4.1.6

• V4.0.23

• V4.1.7

• V4.0.24

• Upgrade to the latest version.

P2

An error occurs when ai_gen is used with to_file.

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

A type conversion error causes the ai_gen function to fail when used with to_file.

• V4.1.5

• V4.0.21

• V4.1.6

• V4.0.22

• Upgrade to the latest version.

P1

If a virtual warehouse consumes a source table's binlog in lightweight connection mode without loading the Table Group of the source table, the instance may be unable to create new connections. This mode is active if the Flink source table parameter connection.fixed.enabled is enabled, or is enabled by default on certain instance versions.

During initialization in lightweight connection mode, requests retry automatically because the current virtual warehouse has not loaded the Table Group. During these retries, the error-handling path incorrectly holds a global lock, which blocks new connection requests.

• V3.1.13

• V3.2.10

• V4.0.0

• V4.0.8

• Upgrade to the latest version.

• If the instance has sufficient connections, set the connection.fixed.enabled parameter on the source table to false.

P1

An incremental dynamic table that contains a stream-stream join may fail during its first refresh or when you run REFRESH OVERWRITE.

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

If the table definition includes an aggregation based on the stream-stream join result, the aggregation result might be incorrect.

The first incremental refresh may occasionally include recently deleted data in its calculation, leading to errors or incorrect results.

• V3.2.5

• V4.0.1

• V4.1.1

• V4.0.21

• V4.1.6

• Upgrade to the latest version.

P2

When the array_to_string function is called with two arguments, NULL values in the input data are included in the calculation. This behavior is inconsistent with PostgreSQL, which excludes NULL values.

A logic defect in the HQE engine affects two-argument calls to the array_to_string function.

• V3.0.1

• V3.1.1

• V3.2.1

• V3.0.46

• V3.1.25

• V3.2.24

• Upgrade to the latest version.

Severity

Description

Cause

Affected versions

Fixed versions

Workaround

P2

A query fails if it uses a JOIN and is processed by the PQE execution engine.

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

A mismatch between the output columns of the JOIN operator and the input columns for the PQE execution engine causes the error.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.33

• V3.2.24

• V4.0.13

• Rewrite the SQL to avoid using the PQE execution engine.

• Upgrade to the latest version.

P2

Using the BETWEEN operator in a query processed by the PQE execution engine causes an error.

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

The PQE execution engine does not support the BETWEEN operator.

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.13

Upgrade to the latest version.

P1

Filtering on a timestamp column used as a segment or cluster key fails to filter the result set.

An issue in the storage engine's segment key extraction logic causes incorrect filtering.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.24

• V4.0.13

Upgrade to the latest version.

P1

After an upgrade to V4.0, memory usage continuously increases and does not stabilize or decrease, even when no queries are active.

A memory leak occurs in the V4.0 result cache path when processing dictionary arrays.

• V4.0.0

• V4.0.10

• To work around this issue, disable the feature flag:

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

• Upgrade to the latest version.

P2

When a CTE is reused, the system cannot generate a query plan and returns an error.

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

The query optimizer (QO) does not correctly update the CTE count, which causes the error.

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.7

• As a workaround, change the CTE strategy to inlining:

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

• Upgrade to the latest version.

P2

Accessing array elements using range notation, such as array_column[1:1], causes an error.

A bug in the query optimizer's (QO) handling of array elements causes this error.

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.13

Upgrade to the latest version.

P1

Data may be missing from PQE results if the shard count exceeds the bucket count and the following conditions are met. This occurs when PQE output bypasses the shuffle phase and is directly used in JOIN or UNION ALL operations with the scan results from another columnar table in the same table group.

• A columnar table uses a primary key index, which triggers a point seek.

• Data is processed directly by PQE.

When a columnar table uses a primary key index, the plan generated by the query optimizer (QO) does not include a Gather operator. If the bucket count is not equal to the shard count and a bucket contains multiple shards, data loss may occur because PQE incorrectly calculates the shard_count to bucket_count ratio.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.10

Upgrade to the latest version.

P2

• Rebuilding a table with a name containing uppercase letters (but no other special characters) fails. The progress view shows an error indicating that the view could not be found.

• Rebuilding a table with column names containing uppercase letters (but no other special characters) fails. The progress view reports a missing column in the temporary table.

The rebuild process in older versions did not correctly handle case-sensitive identifiers.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.40

• V3.2.25

• V4.0.13

Upgrade to the latest version.

P2

A subquery that contains a CASE WHEN expression causes the following error:

ERROR: column "xxx" does not exist

A query optimizer bug prevents it from generating a valid plan for this scenario.

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V4.1.0

• V3.0.53

• V3.1.41

• V3.2.25

• V4.0.14

• To work around this issue, disable the feature flag:

  ALTER DATABASE <database_name> SET hg_experimental_reuse_switch_case_expression = 'off';

• Upgrade to the latest version.

P1

When a Flink job consumes Hologres binlog, if its source table is defined with a subset of columns from the physical table, the job may ingest unexpected NULL values.

The Hologres connector for Flink does not correctly handle binlog consumption with projected columns.

• Flink VVR 11.3 or 11.4 with Hologres V4.0.1 or later.

• Hotfixes for Flink VVR 11.3 and 11.4 were released on January 9, 2026.

• After the fix is released, restart the Flink job.

• Before the fix is available, add the following configuration to the WITH clause of the Flink source table and restart the job: source.binlog.project-columns.enabled' = 'false'.

P1

Completed queries may not be cleaned up correctly, leaving residual transactions that hold table locks.

A defect in the garbage collection (GC) logic for some completed queries leads to residual query identifiers (query_id).

• V2.2.0 and earlier

• V3.0.0

• V2.2.32

• V3.0.12

• Upgrade to the latest version.

• Manually clean up residual queries by running the following SQL command:

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

Severity

Description

Cause

Affected versions

Fixed versions

Workaround

P0

Querying a DLF Paimon Postpone table reads uncompacted committed data, which can cause duplicate primary keys.

The behavior of the Paimon SnapshotReader class changed after the Hologres upgrade to V3.2.12:

• Older Paimon SDK versions: The SnapshotReader automatically added the onlyReadRealBuckets option for Postpone tables. This option limited reads to final, compacted data.

• Newer Paimon SDK versions removed this automatic logic. You must now manually configure this option for the SnapshotReader to read only the final data.

• V3.2.12

• V4.0.0

• V3.2.24

• V4.0.11

• Upgrade to the latest version.

P1

When using a DLF foreign table with bucket_num=-2 for a Paimon table, an incorrect join plan for multi-table joins can produce inaccurate results.

When the bucket_num of a Paimon table is set to -2 in scenarios that involve multi-table JOINs, an incorrect JOIN plan is generated, which prevents data from being joined effectively and results in inaccurate query results.

• V3.2.0

• V4.0.0

• V3.2.21

• V4.0.8

• As a temporary workaround, disable the feature with the following SQL command:

  ALTER DATABASE <database_name> set hg_experimental_use_shard_info_in_hashed_dist_spec=off;  

• Upgrade to the latest version.

P1

Using a CTE expression produces inconsistent results between split and combined execution.

When a CTE expression is used, the system fails to report an intermediate result failure to the FE, which leads to an incorrect final result.

• V3.2.0

• V4.0.0

• V3.2.17

• V4.0.6

• Upgrade to the latest version.

P1

Even when a user has the required permissions, queries on hologres.hg_query_log and hologres.hg_table_info return empty results.

The system fails to report data for hologres.hg_query_log and hologres.hg_table_info.

• V2.0.39

• V2.2.16

• V3.0.0

• V2.0.47

• V2.1.44

• V2.2.24

• V3.0.2

• V3.1.0

• V3.2.0

• V4.0.0

• Upgrade to the latest version.

P0

During an incremental refresh of a dynamic table with a multi-stream join, if only one stream contains data and that data includes retractions, the refresh produces incorrect results compared to a direct query.

During an incremental refresh of a dynamic table, data retraction from a single stream is not handled correctly. Consequently, the system does not remove rows that should be deleted from the result table, which makes the result table incorrect.

• V4.0.1

• V4.0.9

• First, modify the table data. Then, use refresh overwrite to correct the erroneous data. Run the following two SQL commands:

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

• Upgrade to the latest version.

P1

After an upgrade to V4.0, worker OOM errors may occur. The error messages are similar to the following:

1. Error: ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

2. Error: ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

To cache more data in memory, V4.0 optimizes the memory structure. However, the new structure has a defect when handling the Decimal type. When a table that contains Decimal columns participates in a hash join, the instance may generate a core dump.

• V4.0.0

V4.0.10

• As a temporary workaround, disable query memory optimization by using the following SQL command:

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

• Upgrade to the latest version.

P1

Queries on a non-empty MaxCompute Append Delta Table incorrectly return an empty result set.

A bug in the split cache causes queries to return an empty result.

• V4.0.0

V4.0.9

• As a temporary workaround, disable the split cache using the command below.

ALTER DATABASE <database_name> set hg_experimental_enable_maxcompute_sdk_splits_cache=off;

• Upgrade to the latest version.

P0

In V4.0, when you use a logical partitioned table that has a primary key and a clustering key, duplicate primary key values can occur.

To improve write performance for logical partitioned tables, V4.0 supports multi-partition flush. However, a bug in the cluster index processing logic during this operation can corrupt the cluster index in AliORC files (data files for internal columnar tables) stored on Pangu. A corrupted cluster index can make existing data unreadable. Consequently, during an update, the system fails to find the old data and inserts a new row, creating a duplicate.

• V4.0.0

V4.0.9

• Upgrade to the latest version. After the upgrade, the system adds logic to detect corrupted files. If a corrupted file is scanned, the system reports an error: clustered_index size [x] incorrect. If this error occurs, run a full compaction on the affected table to repair it. For more information, see Partitioned Table FAQ.

P1

After an upgrade to V4.0, worker OOM errors may occur. The error messages are similar to the following:Error 1: ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

Error 2: ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

To cache more data in memory, V4.0 optimizes the memory structure. However, the new structure miscalculates the data size, underestimating the memory required and causing a worker OOM.

• V4.0.0

V4.0.7

• As a temporary workaround, disable the result cache using the command below.

ALTER DATABASE <database_name> set hg_experimental_enable_result_cache=off;

• Upgrade to the latest version.

Level

Description

Cause

Affected versions

Fixed versions

Workaround

P1

In Flink real-time write scenarios, dropping a user and then recreating one with the same name and permissions may result in permission errors for the new user, even on a new connection.

An issue with the user permission cache update strategy in the FixedFE component.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.21

• V4.0.9

• Upgrade to the latest version.

P1

When using stream mode for an incremental refresh of a Dynamic Table, performing INSERT, UPDATE, or DELETE operations on the source table immediately followed by TRUNCATE or INSERT OVERWRITE can cause subsequent refreshes to contain incorrect data.

If TRUNCATE or INSERT OVERWRITE immediately follows DML operations (INSERT, UPDATE, or DELETE) on the source table during an incremental refresh, the Dynamic Table may process duplicate DELETE messages for the same primary key, leading to incorrect data.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• Upgrade to the latest version.

P2

Running SELECT hg_rebalance_instance() to rebalance a general-purpose instance causes a shard group not found error.

An incorrect default parameter is passed when rebalancing a general-purpose instance.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• Upgrade to the latest version.

P2

During a scaling operation, a ShardPermissionDenied error may rarely occur on a table group's primary and secondary virtual warehouses, causing brief write failures.

The system is designed to convert a ShardPermissionDenied error into a retryable kShardHotMigrationInProgress error during scaling. However, this conversion fails, and the original error is returned to the client.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• Upgrade to the latest version.

P2

After switching to the Common Table access path for MaxCompute, refreshing a Dynamic Table that uses a MaxCompute external table fails with the following error:

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

The method for passing a query plan for a Dynamic Table differs from that of a regular OLAP query. During transmission, the binary data of the plan is corrupted, causing the filter to fail parsing.

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.36

• V3.2.17

• V4.0.6

• Disable the Common Table access path as a temporary workaround.

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

• Upgrade to the latest version.

P2

When using the standard PostgreSQL authorization model, even after a user is granted Owner permission on a Dynamic Table, refreshing a history table or partition as the owner may still result in a Permission Denied error.

The identity used for the refresh is cached. After permissions change, subsequent refreshes incorrectly use the outdated cached identity, triggering the error.

• V3.1.0

• V3.2.0

• V4.0.0

• To be fixed

• Upgrade to the latest version.

P2

Querying data in DLF with a range filter on a timestamp column causes the following error:

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

The system mishandles the literal type, incorrectly treating it as a long literal.

• V3.2.0

• V4.0.0

• V3.2.17

• V4.0.6

• Disable the Bigmeta access path as a temporary workaround.

ALTER DATABASE <database_name> set hg_experimental_enable_big_meta=off;

• Upgrade to the latest version.

P2

When inserting fewer than 10 rows with a DML statement into a table whose primary key contains a boolean column, the following error occurs:

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

The query engine converts a boolean array to a uint8 array. When hybrid DML creates a row group filter, it does not account for this scenario. This causes a mismatch between the literal type (bool) and the actual value type (long) in the row group filter.

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.7

• Disable hybrid DML as a temporary workaround.

ALTER DATABASE <database_name> set hg_experimental_enable_hybrid_dml = off;

• Upgrade to the latest version.

P2

Using a remote UDF causes the following error:

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

The error is caused by a defect in the multi-threaded invocation handling logic.

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.8

• Upgrade to the latest version.

P1

When using stream mode for an incremental refresh of a Dynamic Table, a refresh that immediately follows a source table compaction can result in out-of-order incremental data.

Out-of-order incremental events for the same key can cause incorrect results in the sink table.

• V3.1.0

• V3.2.0

• V3.1.23

• V3.2.6

• Upgrade to the latest version.

P1

When you use the REBUILD command:

• binlog disabled: If the binlog is disabled, rebuilding a physical partitioned table into a logical one incorrectly enables the binlog on the resulting table.

• binlog enabled: If the binlog is enabled, rebuilding a physical partitioned table into a logical one fails to enable the binlog on the resulting table.

The binlog handling logic is incorrect during a rebuild partition to logical partition operation.

• V3.1.1

• V3.2.1

• V4.0.1

To be fixed

P2

When you use create table as to read a DLF external table, the following error message is displayed:

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

The create table as statement causes a permission read error when reading a DLF V2.0 table.

• V3.0.1-V3.0.49

• V3.1.1-V3.1.34

• V3.2.1-V3.2.16

• V4.0.1-V4.0.4

• V3.0.50

• V3.1.35

• V3.2.17

• V4.0.6

• Upgrade to the latest version and use the REBUILD command instead.

P2

If data masking is applied to the source table, the error message the insert table has not set security label is reported when you use a CREATE TABLE ... AS statement. An example SQL statement is as follows:

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

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

The data masking settings are not passed to the create table as process, which causes an error.

• V3.1.1-V3.1.32

• V3.2.1-V3.2.12

• V4.0.1-V4.0.2

• V3.1.33

• V3.2.13

• V4.0.3

• Upgrade to the latest version and use the REBUILD command instead.

P0

When you use higher-order array functions, if all elements in the result array are identical, the result may be incorrectly deduplicated to a single-element array. Examples:

create table tbl1(col1 text[]);
insert into tbl1 values(array['1', '1']);
select hg_array_map(lambda[x => '1' || '1'], col1) from tbl1; 
-- Returns {11}, but expected {11, 11}

create table tbl2(col1 jsonb);
insert into tbl2 values('{"a": "a", "b": "b", "c": null}');
select hg_array_map(lambda[x => col1 ->> x], array['c', 'd']) from tbl2; 
-- Returns {NULL}, but expected {NULL, NULL}

select hg_array_map(lambda[x => case when col1 ->> x is null then '' else col1 ->> x end], array['c', 'd']) from tbl2;
-- Returns {''}, but expected {'', ''}

select hg_array_map(lambda[x => case when col1 ->> x is null then '1' else col1 ->> x end], array['c', 'd']) from tbl2;
-- Returns {1}, but expected {1, 1}

A defect in the array calculation framework causes it to incorrectly handle arrays where all elements are identical.

• V3.2.1-V3.2.16

• V4.0.1-V4.0.5

• V3.2.17

• V4.0.6

• Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P0

When using the Table Resharding feature in HoloWeb, if a task fails and is then canceled, the system does not correctly clean up the temporary table.
Manually running DROP TABLE on this temporary table then causes the frontend (FE) to become unresponsive.

Defective cleanup function in HoloWeb.

Affected versions:

• V2.0.24

Fixed versions:

• V2.2.28

Upgrade to the latest version.

P2

The HG_MOVE_TABLE_TO_TABLE_GROUP (resharding) function fails if the target table name contains special characters or is a keyword. The function fails silently, leaving the table group unchanged.

The HG_MOVE_TABLE_TO_TABLE_GROUP function incorrectly handles character escaping.

Affected versions: All versions

Fixed versions: None. See the workaround.

Upgrade to V3.1 or later and use the Rebuild feature.

P2

In pay-as-you-go bills for Hologres Serverless Computing resources, the instance ID field is incorrectly displayed as <instance_id>_<uid>_<region_id>. The expected display is <instance_id>.

Underlying configuration issue.

This issue is not version-specific and affects bills generated from 2025-09-09 16:00:00 to 2025-10-14 16:00:00.

The issue was resolved. Bills generated after 2025-10-14 16:00:00 are correct.

Process bills from the affected time range separately.

Level

Description

Cause

Affected and fixed versions

Workaround

P0

During a shard rebalance operation (such as scaling or restarting), if multiple requests complete simultaneously, background processes may fail. This can lead to read and write failures on the instance.

The backend incorrectly processes multiple requests that complete at the same time.

Affected version: V3.0.9.

Fixed versions: V3.0.14 and later.

Upgrade to the latest version.

P0

When you import data from a Hologres foreign table to an internal table, the adaptive import feature can cause data loss if all the following conditions are met:

• Data is imported using an INSERT INTO ... SELECT ... statement.

• The system automatically adjusts the import speed due to high system resource pressure. If the read operation on the foreign table falls back to the SQE path during this adjustment, some data segments might be skipped, resulting in partial data loss.

When foreign table reads fall back to the SQE path, the adaptive import feature may drop data segments, causing data loss.

Affected versions:

• V3.0.1 to V3.0.46.

• V3.1.1 to V3.1.27.

• V3.2.1 to V3.2.9.

Fixed versions:

• V3.0.47 and later.

• V3.1.28 and later.

• V3.2.10 and later.

Disable the adaptive import feature at the instance level by setting the following GUC:

ALTER ROLE ALL SET hg_experimental_enable_adaptive_adjust_bulkload_dop = off;

P1

After you configure data masking, an UPDATE operation on a table can return unmasked data in query results. For example:

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

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

When data masking is enabled, the UPDATE statement incorrectly handles masked fields.

Affected versions:

• V3.1.0-V3.1.31

Fixed versions:

• V3.1.32

Upgrade to the latest version.

P1

After you restart an instance, dynamic tables no longer refresh automatically.

An issue in the backend scheduling system causes this behavior.

Affected versions:

• V3.0.0-V3.0.45

• V3.1.0-V3.1.24

• V3.2.0-V3.2.6

Fixed versions:

• V3.0.46

• V3.1.25

• V3.2.7

• V4.0.0

Upgrade to the latest version.

P1

For a dynamic table with logical partitions and auto-refresh enabled, when an active partition becomes inactive, it may fail to switch from incremental refresh to full refresh mode. This results in continuous storage growth.

The system incorrectly handles the state transition of active partitions in a dynamic table.

Affected versions:

• V3.1.0-V3.1.23

• V3.2.0-V3.2.6

Fixed versions:

• V3.1.24

• V3.2.7

Upgrade to the latest version.

P2

When you configure a dynamic table with a nullable clustering key, executing an ALTER DYNAMIC TABLE statement fails with the error clustering_key should not be nullable.

The ALTER DYNAMIC TABLE statement fails to correctly infer the properties of the clustering key.

Affected versions:

• V3.1.0-V3.1.31

• V3.2.0-V3.2.11

Fixed versions:

• V3.1.32

• V3.2.12

Upgrade to the latest version.

P2

For a column-oriented table without a clustering key, duplicate primary keys can occur. This issue can arise if you perform an offline import using INSERT ON CONFLICT DO UPDATE and then perform real-time writes.

The system incorrectly handles primary key data during an offline import. As a result, subsequent real-time writes fail to detect the existing keys, leading to potential primary key duplication.

Affected versions:

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

Fixed versions:

• V3.1.30

• V3.2.10

• V4.0.2

Upgrade to the latest version.

P2

When you perform an INSERT ON CONFLICT operation with duplicate primary keys, the system may still report a duplicate key value violates unique constraint error, even if the hg_experimental_affect_row_multiple_times_keep_last GUC is enabled.

When duplicate data is encountered, the hg_experimental_affect_row_multiple_times_keep_last GUC does not take effect, causing a primary key constraint violation.

Affected versions:

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

Fixed versions:

• V3.1.30

• V3.2.10

• V4.0.2

Upgrade to the latest version.

P2

After an upgrade to V3.1, querying a view that contains masked columns may fail with a relation "xxx" does not exist error.

This error occurs because the data masking feature in V3.1 incorrectly processes table names within views.

Affected versions:

• V3.1.0-V3.1.22

• V3.2.0-V3.2.5

Fixed versions:

• V3.1.23

• V3.2.6

Upgrade to the latest version.

P2

When you use hg_insert_overwrite to read from a related foreign table in an external database, the SQL query may hang.

The hg_insert_overwrite command times out when accessing tables in the external database, causing the query to hang.

Affected versions:

• V3.1.0-V3.1.21

• V3.2.0-V3.2.4

Fixed versions:

• V3.1.22

• V3.2.5

Upgrade to the latest version.

Level

Description

Cause

Versions

Workaround

P1

A worker node could hang when a query request completes, blocking subsequent DDL operations and queries with a LIMIT clause on related tables. This issue was triggered when the query request:

• Resulted in an out-of-memory (OOM) error.

• Was manually canceled.

• Was manually canceled or terminated by an exception.

The cause was a defect in the query engine's resource cleanup process after a query finished.

Affected versions:

• V3.1.18

• V3.2.3

Fixed versions:

• V3.1.21 and later

• V3.2.5 and later

• Upgrade to the latest version.

• If a hang occurs, restart the instance or virtual warehouse.

• Alternatively, disable the new query engine by running this command:

  ALTER ROLE ALL SET hg_experimental_enable_qe_v2=off;

P1

When using Holo Client V2.6.0 to connect to a Hologres instance with an Alibaba Cloud AccessKey (for an Alibaba Cloud account, RAM user, or RAM role), the connection failed during a specific time window each day. This time window depended on the client time zone. For example, in UTC+8, connections failed from 00:00:00+08 to 08:00:00+08, and in UTC-5, they failed from 19:00:00-05 to 00:00:00-05.

The cause was an issue with time zone handling in Holo Client V2.6.0.

This issue is specific to Holo Client V2.6.0 and is independent of the Hologres instance version.

Upgrade Holo Client to V2.6.1 or later.

P0

In Hologres V3.1, an instance could enter a continuous restart loop if it had a read-only dynamic table that consumed base table data in stream mode.

This occurred because data flushing failed when the dynamic table was in a read-only state, which triggered continuous instance restarts.

Affected versions:

• V3.1.1 to V3.1.20

• V3.2.1 to V3.2.2

Fixed versions:

• V3.1.21 and later

• V3.2.3 and later

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

When a data import job using Serverless Computing fails, it may leave undeleted intermediate files, increasing the instance's storage usage.

The cleanup logic for intermediate files can occasionally fail.

Affected: V3.1.1.

Fixed in: V3.1.20 and later.

• Restart the instance to clean up intermediate files.

• Upgrade to the latest version.

P2

Querying data from an Iceberg foreign table by using Data Lake Formation (DLF) returns an empty result set.

A file parsing error occurs when querying the Iceberg table, resulting in an empty result set.

Affected: V3.1.1 to V3.1.16.

Fixed in: V3.1.17 and later.

Upgrade to the latest version.

P2

When you query a table that contains a generated column, the query fails with the error ERROR: ORCA failed to produce a plan : Query Translation: No variable entry found due to incorrect normalization of query. Example SQL:

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

CREATE VIEW v1 AS SELECT * FROM lpt1;

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

The query fails because the optimizer incorrectly translates the generated column.

Affected: V3.1.1 to V3.1.16.

Fixed in: V3.1.17 and later.

Upgrade to the latest version.

P1

When you create a Dynamic Table and the source query contains a BOOLEAN data type, the refresh operation fails with the error ERROR: Internal error: HGERR_code XX000 HGERR_msge can not get pg type string %s: id: UINT8.

The refresh operation fails because the Dynamic Table feature incorrectly infers the data type for BOOLEAN fields.

Affected: V3.1.1 to V3.1.15.

Fixed in: V3.1.16 and later.

Upgrade to the latest version.

P2

After an upgrade to Hologres V3.1, the hg_dynamic_table_state_size function returns an empty result set.

The hg_dynamic_table_state_size function is not compatible with V3.1.

Affected:

• V3.1.1 to V3.1.15

• V3.2.0 to V3.2.1

Fixed in:

• V3.1.16 and later

• V3.2.2 and later

Upgrade to the latest version.

P2

In Hologres V3.1, dropping a Dynamic Table configured for incremental refresh does not delete its state table.

Dropping a Dynamic Table that uses incremental refresh fails to clean up the associated state table.

Affected: V3.1.1 to V3.1.12.

Fixed in: V3.1.13 and later.

Upgrade to the latest version.

P2

Using 64-bit RoaringBitmap functions, such as rb_or_cardinality_agg, across different schemas results in the error: Unsupported agg function:public.rb_or_cardinality_agg.

Incorrect schema inference for 64-bit RoaringBitmap functions causes cross-schema queries to fail.

Affected:

• V3.1.1 to V3.1.11

• V3.2.0

Fixed in:

• V3.1.12 and later

• V3.2.1 and later

Upgrade to the latest version.

P2

Creating a Dynamic Table as a logical partitioned table fails if the base table has a NOT NULL column, returning the error: failed:the index xx "xxx" should not by nullable. Example SQL:

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

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

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

The failure is caused by incorrect inference of the NOT NULL attribute for the Dynamic Table.

Affected:

• V3.1.1 to V3.1.11

• V3.2.0

Fixed in:

• V3.1.12 and later

• V3.2.1 and later

Upgrade to the latest version.

P2

If a materialized view on a single table contains a SUM(DECIMAL) aggregation, the instance may briefly restart.

When calculating SUM(DECIMAL) for a materialized view, a memory misalignment issue can cause the instance to generate a core dump.

Affected:

• V3.1.1 to V3.1.17

• V3.0.41 to V3.0.43

• V3.2.0 to V3.2.1

Fixed in:

• V3.1.17 and later

• V3.0.44 and later

• V3.2.2 and later

Upgrade to the latest version.

P1

After an upgrade to Hologres V3.0.41, querying a MaxCompute foreign table through the CommonTable access path causes a slow increase in memory usage.

A memory leak occurs when querying MaxCompute foreign tables through the CommonTable access path.

Affected:

• V3.1.1 to V3.1.17

• V3.0.41 to V3.0.43

• V3.2.0 to V3.2.1

Fixed in:

• Version 3.1.17 or later.

• V3.0.44 and later

• V3.2.2 and later

Upgrade to the latest version.

P0

In certain concurrent scenarios, running DML operations with Serverless Computing on a table while executing TRUNCATE TABLE or DROP TABLE on the same table can cause read/write exceptions on the table's shard. This is caused by an internal engine state synchronization issue.

A concurrency issue in the engine can cause an abnormal internal state within a shard, making it temporarily unable to serve read or write requests. This issue may also impact access to other tables.

Affected:

• V2.1.45 and earlier

• V2.2.45 and earlier

Fixed in:

• V2.1.46

• V2.2.46

• V3.0.27 and later

• V3.1.1 and later

• Temporary workarounds:

  • Schedule DML and TRUNCATE TABLE/DROP TABLE operations to run at different times.

  • Do not use Serverless Computing to perform DML operations.

• Recommended solution:

  Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P1

A compute node could occasionally restart when you scaled out a virtual warehouse instance.

Concurrent DML task and compaction task operations on a table could trigger this issue during the scale-out.

Affected version: V3.0.1.

Fixed versions: V3.0.28 and later.

Upgrade to the latest version.

P1

An instance could restart unexpectedly when the JSONB columnar storage optimization was used with a GIN index.

An incompatibility between the JSONB columnar storage optimization and GIN index caused this issue.

Affected version: V3.1.1.

Fixed versions:

• V3.0.42 and later.

• V3.1.10 and later.

• Delete the GIN index from the table.

• Upgrade to the latest version.

P2

An instance could restart when you refreshed a dynamic table based entirely on views.

A processing error caused a core dump when refreshing a dynamic table that used views as base tables.

Affected version: V3.1.8.

Fixed versions: V3.1.9 and later.

Upgrade to the latest version.

P2

In the incremental refresh mode for a dynamic table, a query with the ARRAY_AGG function returned an empty result instead of null when the aggregate filter removed all data.

None.

Affected versions:

• V3.0.40.

• V3.1.7.

Fixed versions:

• V3.0.41 and later.

• V3.1.8 and later.

Upgrade to the latest version.

P1

The property-based funnel function (finder_funnel) returned incorrect results when a time zone was specified. Example SQL:

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

The finder_funnel function incorrectly discarded the specified time zone and defaulted to UTC.

Affected version: V3.0.40.

Fixed versions: V3.0.41 and later.

Upgrade to the latest version.

P2

In a virtual warehouse instance, the PG_RELATION_SIZE, PG_DATABASE_SIZE, and HOLOGRES.HG_RELATION_SIZE functions returned an incorrect storage size.

In a virtual warehouse instance, using PG_RELATION_SIZE to query the storage size results in an overestimated value, leading to an incorrect result.

Affected version: V3.0.39.

Fixed versions: V3.0.40 and later.

Upgrade to the latest version.

P2

In incremental refresh mode, a dynamic table refresh failed with an ERROR: internal error: Filter has 1 rows but length of columns error if the base table contained multiple duplicate rows.

The incremental refresh process failed to correctly handle multiple duplicate rows within a single refresh operation.

Affected version: V3.0.39.

Fixed versions: V3.0.40 and later.

Upgrade to the latest version.

P2

The incremental refresh operation for a dynamic table failed with an XX000: internal error: Not Implements error if the operation involved a multi-table join and one of the tables contained an ARRAY field.

The incremental refresh process for multi-table joins could not correctly handle tables with an ARRAY field.

Affected versions:

• V3.0.38.

• V3.1.2.

Fixed versions:

• V3.0.39 and later.

• V3.1.3 and later.

Upgrade to the latest version.

P1

An instance could restart when committing a transaction that wrote to a table with logical partitions, if high partition key cardinality caused the partition count to exceed the 5,200 limit.

The instance created a core dump because during a transaction commit, the process detected that the number of logical partitions in the table exceeded the limit.

Affected version: V3.1.1.

Fixed versions: V3.1.9 and later.

Clean the partition key data in your import jobs to prevent creating an excessive number of partitions.

Level

Description

Cause

Affected, fixed versions

Workaround

P2

Fixed an issue where reading from a MaxCompute foreign table failed with an error: ERROR: XX000: internal error: max compuate csdk get next error: storage/formats/orcfile/orc_reader.cpp(362): RetryableStorageException: ODPS-0010000:BadAllocError:allocated pointer 1b658028 not aligned with 64.

An interface conversion error occurred when reading the MaxCompute foreign table.

Affected versions: V3.0.1 to V3.0.35.

Fixed versions: V3.0.36 and later.

Upgrade to the latest version.

P2

Fixed an issue where using hg_create_table_like to copy a table comment failed.

The hg_create_table_like function incorrectly copied the table comment as a column comment.

Affected versions: V3.0.1 to V3.0.33.

Fixed versions: V3.0.34 and later.

Upgrade to the latest version.

P2

Fixed an issue where a query on a data lake foreign table failed with an error: ERROR: failed to get foreign table split from hive:Failed to generate splits: IllegalStateException: Weights must be non-negative.

A data format conversion error occurred when reading the foreign table.

Affected versions: V3.0.1 to V3.0.30.

Fixed versions: V3.0.31 and later.

Upgrade to the latest version.

P1

Fixed an issue where using the ARRAY_AGG function could intermittently cause continuous memory growth.

A memory leak in the ARRAY_AGG function.

Affected versions: V3.0.1 to V3.0.29.

Fixed versions: V3.0.30 and later.

Upgrade to the latest version.

P2

Fixed an issue where a CTE query containing a nested loop join failed with an error: Cannot open a fragment with explicit_seek set to false.

The optimizer incorrectly deduced the join order.

Affected versions: V3.0.1 to V3.0.27.

Fixed versions: V3.0.28 and later.

Upgrade to the latest version.

P2

Fixed an issue where using the GENERATE_SERIES function with DECIMAL type fields failed with an error: generate series first and second arguments should has same type.

The optimizer incorrectly deduced the precision for the DECIMAL type field.

Affected versions: V3.0.1 to V3.0.25.

Fixed versions: V3.0.26 and later.

Upgrade to the latest version.

P2

Fixed an issue where the query_id field in the hg_stat_activity view was inaccurate when engine_type was set to {PG}.

hg_stat_activity reported a disordered query_id when engine_type was set to {PG}.

Affected versions: V3.0.1 to V3.0.25.

Fixed versions: V3.0.26 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

Fixed an issue where using a window function, such as ROW_NUMBER() OVER, to process the lc_state_split_idx field caused an ORCA failed to produce a plan error.

The window function incorrectly identified the lc_state_split_idx field as a keyword, causing an incorrect truncation. This prevented the generation of an execution plan and caused the SQL query to fail.

Affected: V3.0.24 and earlier.

Fixed: V3.0.25 and later.

Upgrade to the latest version.

P1

Fixed an issue that prevented a manually specified distribution key in a dynamic table from taking effect.

An engine inference error caused the manually specified distribution key to be ignored.

Affected: V3.0.24 and earlier.

Fixed: V3.0.25 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workarounds

P1

When connecting to a Hologres instance with a BI or developer tool, unauthorized users can see database, schema, and table metadata.

Access control for metadata is not sufficiently strict.

Affected: V3.0.23 and earlier.

Fixed: V3.0.24 and later.

Upgrade to the latest version.

P2

When joining a MaxCompute foreign table with a hologres_fdw foreign table, the query fails with the error error: Build desc failed: Fetch table group shards failed on meta proxy.

A logic error occurs during shard pruning on an internal table during a join between a hologres_fdw foreign table and a MaxCompute foreign table.

Affected: V3.0.22 and earlier.

Fixed: V3.0.23 and later.

Upgrade to the latest version.

P2

After a Hologres instance is upgraded to V2.2, using the GENERATE_SERIES set-returning function to process a DECIMAL field fails with the error error: generate series first and second arguments should has same type.

The query fails because the optimizer incorrectly infers the precision of the DECIMAL type when the GENERATE_SERIES function processes a DECIMAL field.

Affected: V2.2.22 and earlier.

Fixed: V2.2.23 and later.

Upgrade to the latest version.

P2

When a data masking rule for an account is set to all:unmasked, the rule does not take effect, and the queried data is still masked.

After a data masking rule is set, the system fails to correctly evaluate the rule for the account.

Affected:

• V3.0.1 and earlier.

• V2.2.21 and earlier.

Fixed:

• V3.0.2 and later.

• V2.2.22 and later.

Upgrade to the latest version.

P2

When consuming Hologres binary logs in JDBC mode, jobs may throw exceptions such as Binlog Convert Failed and Java heap space, or data consumption from some shards may stop unexpectedly.

If a downstream Flink operator experiences backpressure during binary log consumption, data from the source table is not consumed promptly. This causes the backend to throw a timeout exception. The gateway then incorrectly forwards this exception to the client, causing the data consumption job to hang or fail with a parsing error.

• Affected: V2.2.21 and earlier.

• Fixed: V2.2.22 and later.

Upgrade to the latest version and restart the Flink job.

P2

If column-oriented storage optimization is enabled for a JSONB column that also has a bitmap index, flush and compaction may fail after data is written. This increases instance storage consumption and memory usage.

A defect in the JSONB column-oriented storage optimization prevents it from correctly handling a bitmap index on the BINARY type.

Affected:

• V3.0.1 to V3.0.9.

• V2.2.31 and earlier.

Fixed:

• V3.0.10 and later.

• V2.2.32 and later.

• Upgrade to the latest version.

• Alternatively, disable column-oriented storage optimization for the table and rebuild the table.

Level

Description

Cause

Versions

Workarounds

P2

The array_agg function returns incorrect results when used in a window function. Example:

CREATE TABLE ttt(a text, b int);
INSERT INTO ttt VALUES ('0101', 1), ('0102', 2), ('0103', 3);
SELECT a, array_agg(b) OVER (ORDER BY a DESC) FROM ttt;
--Execution result:
a	array_agg
0103	{3}
0102	{2}
0101	{1}

--Correct result:
a	array_agg
0103	{3}
0102	{3,2}
0101	{3,2,1}

The array_agg function produces incorrect results with a window function due to a calculation logic error.

Affected versions:

• V3.0.1 to V3.0.21.

• V2.2.38 and earlier.

Fixed in:

• V3.0.22 and later.

• V2.2.39 and later.

Upgrade to the latest version.

P2

Querying an external table fails if a column name contains uppercase characters:

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

A case conversion error causes queries on external tables with uppercase column names to fail.

• Affected versions: V3.0.18 and earlier.

• Fixed in: V3.0.19 and later.

Upgrade to the latest version.

P2

Querying a table in DLF fails if an OSS endpoint is not configured. The following error is reported:

SELECT * FROM openlake_demo_dlf.github_events.ods_github_events_raw;

--Error message
ERROR: internal error: external dataset reader missing required oss_endpoint option.

Without a configured OSS endpoint, the system cannot route to the corresponding OSS table, causing the query to fail.

• Affected versions: V3.0.17 and earlier.

• Fixed in: V3.0.18 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected / Fixed versions

Workaround

P2

A full or incremental refresh of a dynamic table containing a DECIMAL field fails with the error column type doesn't match, decimal(28, 10) v.s. decimal(38, 10).

The refresh fails because the system incorrectly infers the precision of the DECIMAL field.

Affected: V3.0.16 and earlier.

Fixed: V3.0.17 and later.

• Manually specify the precision of the DECIMAL field in the query.

• Upgrade to the latest version.

P2

If the query schemas on both sides of a UNION ALL operator are inconsistent, the query fails with the error schema's field number from producers are not equal [1 vs 0].

Incorrect schema inference for the UNION ALL operator causes this error.

Affected: V3.0.16 and earlier.

Fixed: V3.0.17 and later.

Upgrade to the latest version.

P2

Aggregating a SMALLINT field in a dynamic table during an incremental refresh causes an 'unsupported' error.

The incremental refresh process for dynamic tables does not fully support the SMALLINT type.

Affected: V3.0 to V3.0.16.

Fixed: V3.0.17 and later.

Upgrade to the latest version.

P2

After you upgrade a virtual warehouse instance, queries fail with the error CreateFile ignore since it's not leader.

During a virtual warehouse upgrade, the system fails to update table metadata promptly. This causes subsequent queries to use outdated table metadata, leading to errors.

Affected:

• V3.0.12 to V3.0.15.

• V2.0.35 and earlier.

Fixed:

• V3.0.16 and later.

• V2.2.36 and later.

• Restart the upgraded virtual warehouse.

• Upgrade to the latest version.

P1

After an upgrade to Hologres V3.0.12–V3.0.15, dynamic partitioning scheduling can fail for tables that use a TEXT partition key. This failure prevents the creation of new partitioned tables.

The scheduling system mishandles TEXT partition keys, causing an internal conversion to fail. This, in turn, prevents table creation.

Affected: V3.0.12 to V3.0.15.

Fixed: V3.0.16 and later.

Upgrade to the latest version.

P1

After you upgrade Hologres to a version from V3.0 to V3.0.13, queries on MaxCompute foreign tables become slower.

Hologres V3.0 introduced stricter permission checks for accessing MaxCompute table metadata. These new checks cause the frontend (FE) node to make multiple, redundant calls, degrading query performance on MaxCompute foreign tables.

Affected: V3.0 to V3.0.13.

Fixed: V3.0.14 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

When you enable Binlog in Dynamic Table full refresh mode, the Refresh operation reports the error ERROR: internal error: refresh table failed: internal error: new_values is missing col.

When the binary log is enabled for a dynamic table in full refresh mode, inconsistent derivation of hidden columns causes the refresh operation to fail.

Affected versions: V3.0.11 and earlier.

Fixed versions: V3.0.12 and later.

Upgrade to the latest version.

P2

In the SLPM permission model, deleting and then recreating the Orafce extension causes an error: "role slpm xxx already exists".

In the SLPM permission model, dropping the Orafce extension does not completely remove user group permissions. As a result, the user group persists, preventing the extension from being recreated.

Affected versions: V3.0.9 and earlier.

Fixed versions: V3.0.10 and later.

• Switch from the SLPM permission model to the standard PostgreSQL authorization model, then recreate the Orafce extension.

• Upgrade to the latest version.

P2

Refreshing a Dynamic Table that contains a Decimal field causes the error invalid definition of a numeric type.

Incorrect precision inference for the Decimal field causes a precision mismatch during the dynamic table refresh.

Affected versions: V3.0.9 and earlier.

Fixed versions: V3.0.10 and later.

• Manually specify the precision of the Decimal field when you create the dynamic table.

• Upgrade to the latest version.

P2

For queries that run longer than 10 seconds, the Plan column in the metadata warehouse occasionally lacks EXPLAIN ANALYZE results.

Occasional reporting delays for queries that run longer than 10 seconds prevent the Plan column from collecting results.

Affected versions:

• V3.0.8 and earlier.

• V2.2.33 and earlier.

Fixed versions:

• V3.0.9 and later.

• V2.2.34 and later.

Upgrade to the latest version.

P2

Analyzing a table with the BIS type reports the error Not supported type: bsi0.] in cache failed.

This issue occurs because support for analyzing BSI-type fields is incomplete.

Affected versions:

• V3.0.9 and earlier.

• V2.2.31 and earlier.

Fixed versions:

• V3.0.10 and later.

• V2.2.32 and later.

Upgrade to the latest version.

P2

After using hg_insert_overwrite, the generated temporary table is not automatically cleaned up.

The temporary table was not cleaned up because the cleanup mechanism was not triggered during the hg_insert_overwrite process.

Affected versions: V2.2.30 and earlier.

Fixed versions: V2.2.31 and later.

Upgrade to the latest version.

P2

On an instance with frequent DDL operations, performing a TRUNCATE operation while FE node versions are inconsistent prevents the operation from being canceled. This can lead to data inconsistency.

Inconsistent FE node versions can cause the node relay to stall and subsequent DDL operations to fail. As a result, DROP or TRUNCATE operations run during this period cannot be canceled.

Affected versions: V2.2.26 and earlier.

Fixed versions: V2.2.27 and later.

Upgrade to the latest version.

P2

Executing an SQL statement that is too long and exceeds the limit causes the following error: ERROR: Current query length xxx exceeds the limit 10000000.

Hologres limits the length of SQL statements to a default of 10,000,000 characters.

Introduced in versions:

• V2.2.22 and later.

• V3.0.1 and later.

To remove the SQL length limit, set the following parameter:

ALTER DATABASE db_name SET hg_experimental_query_length_limit = 0;

Level

Description

Cause

Affected/fixed versions

Workaround

P1

A concurrent DDL operation on a table may cause a query to hang if it is executed after the database's first DML transaction.

The first DML transaction in a database acquired a table lock. A subsequent, concurrent DDL operation on the same table then caused the system to enter a creation loop, leading to a deadlock that hung the query.

Affected versions: V2.2.24 and earlier.

Fixed versions: V2.2.25 and later.

Upgrade to the latest version.

P2

For a Hologres table that contains a field of the roaringbitmap type, when you use the CREATE FOREIGN TABLE command to create a foreign table for cross-database queries without including the roaringbitmap field, the foreign table is created successfully. However, an error cache lookup failed for type 22243 is reported when you query this table by using SELECT * FROM.

Foreign tables for cross-database queries do not support the roaringbitmap type. This should have been validated when the foreign table was created.

Affected versions: V2.2.24 and earlier.

Fixed versions: V2.2.25 and later.

Upgrade to the latest version.

P2

Using the JDBC prepareStatement method to repeatedly execute the CREATE EXTENSION command causes it to fail with an unrecognized extension: "PostgreSQL JDBC Driver" error. This issue is specific to this method. Example code:

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

Repeatedly running the CREATE EXTENSION command in a loop with the JDBC prepareStatement method corrupted the cache, which caused the failure.

Affected versions:

• V2.2.23 and earlier.

• V3.0.3 and earlier.

Fixed versions:

• V2.2.24 and later.

• V3.0.4 and later.

• Run the CREATE EXTENSION command only once per database.

• Upgrade to the latest version.

P2

The values of result_rows and affected_rows in the metadata warehouse Query Log do not match the actual values.

The metadata warehouse incorrectly reported the result_rows and affected_rows values, which caused the discrepancy.

Affected versions: V2.2.22 and earlier.

Fixed versions: V2.2.23 and later.

Upgrade to the latest version.

P2

Restarting the primary virtual warehouse can slow down point queries on a secondary virtual warehouse.

When the primary virtual warehouse restarted, shards in the secondary virtual warehouse continuously polled the primary shard's status. This polling caused point queries to hang until all shards recovered.

Affected versions: V2.2.21 and earlier.

Fixed versions: V2.2.22 and later.

Upgrade to the latest version.

P2

The BSI_SUM function returns an incorrect result if the sum of all elements in the result array exceeds 2^31.

The function mishandled a data overflow condition.

Affected versions: V2.1.1 and later.

Fixed versions: Pending.

• Upgrade to the latest version after the fix is released.

• Rewrite the SQL query. Example:

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

P2

New connections to a Hologres instance may occasionally time out or hang.

A process within a node occasionally hangs, which prevents that node from creating new connections.

Affected versions: V2.2.22 and earlier, V2.1.42 and earlier, V2.0.45 and earlier, and V1.3.70 and earlier.

Fixed versions: The following versions and later: V3.0.4, V2.2.23, V2.1.43, V2.0.46, and V1.3.71.

• Short-term solution: Restart the instance to temporarily resolve the issue.

• Long-term solution: Upgrade to the latest patch version for your major version.

Level

Description

Cause

Affected and fixed

Workaround

P2

When a virtual warehouse becomes unavailable (for example, while restarting), latency increases for point queries from other virtual warehouses on tables in a table group loaded by that warehouse.

A bug in an internal module of the real-time read/write path causes a virtual warehouse to wait for the table group status during point queries, increasing latency.

Affected: V2.1.1 to V2.2.21.

Fixed: V2.2.22 and later.

Upgrade to the latest version.

P1

Using Fixed Plan for real-time writes at over 1 million QPS creates a small risk of write failures and instance restarts.

A bug in the memory manager of the real-time read/write path.

Affected:

• V2.0.1 to V2.0.43.

• V2.1.1 to V2.1.36.

• V2.2.1 to V2.2.8.

Fixed:

• V2.0.44 and later (V2.0).

• V2.1.37 and later (V2.1).

• V2.2.9 and later (V2.2).

Upgrade to the latest version.

Level

Description

Cause

Affected versions

Workaround

P1

A Flink job reading Hologres binary logs in jdbc or jdbc_fixed mode may hang or trigger a failover if backpressure causes a backend timeout.

An issue in how the gateway returns a backend timeout exception to the client causes data reading to hang or fail with a parsing error.

Affected: V1.3 and later.

Fixed: V2.2.21 and later.

Restart the Flink job from the latest checkpoint and upgrade to the latest version.

P2

In V2.2 and later, the Parallel Query Engine (PQE) executes COUNT DISTINCT operations that use shard pruning (where the execution plan includes a shard prune operator), which degrades performance.

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

The system incorrectly infers the execution plan for COUNT DISTINCT when shard pruning is applied. This causes PQE to execute the query, degrading performance.

Affected: V2.2.1 to V2.2.18.

Fixed: V2.2.19 and later.

• Upgrade to the latest version.

• Replace COUNT DISTINCT with UNIQ.

P2

In the slow query log (the query_log table), the date format for the query_start field is 2024-07-08 22:00:00, while the format for the query_date field is 19700101.

The system collects the query_date field for the slow query log incorrectly.

Affected: V2.2.1 to V2.2.18.

Fixed: V2.2.19 and later.

Upgrade to the latest version.

P2

When writing to a partitioned child table, if the COPY column list includes the partition key column, non-zero values can be incorrectly written into a partition defined for the value 0. This can lead to dirty data in the partition key column.

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

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

# Input
1,0
null,0
\.

When you write to a partitioned child table and the COPY column list includes the partition key column, the system does not validate the partition key when the partition value is 0. This allows dirty data to be written.

Affected: V2.2.1 to V2.2.18.

Fixed: V2.2.19 and later.

Upgrade to the latest version.

P2

When the time zone is explicitly set to SET timezone='+8' in the connection string and a query contains a PQE date function such as to_char, the query incorrectly returns results for the UTC-8 time zone instead of the expected UTC+8. Example:

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

--Incorrect result: 2001-09-27
SET hg_experimental_udf_pushdown_blacklist =timestamptz_to_char;
SET timezone='+8';
SELECT to_char(a, 'YYYY-MM-DD') FROM date_test;

PQE incorrectly calculates the time zone from the connection string when parsing date functions.

Affected: V2.2.1 to V2.2.18.

Fixed: V2.2.19 and later.

Upgrade to the latest version.

P2

Calling the pad_sub_cost function fails with the error Column should be non-nullable but the values contain 609 nulls.

The pad_sub_cost function incorrectly infers the nullable property during calculation, which causes the query to fail.

Affected: V2.2.1 to V2.2.18.

Fixed: V2.2.19 and later.

Upgrade to the latest version.

P0

When you use dynamic partition management and set time_unit to MONTH (monthly dynamic partitions), the system may erroneously create a future partition or delete the current partition.

Starting from V2.2, the dynamic partition management feature supports a custom scheduling start time, but the time calculation for monthly partitions is incorrect.

Affected: V2.2.1 to V2.2.17.

Fixed: V2.2.18 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P1

Executing thehg_insert_overwrite, CREATE TABLE AS,

andCOPY commands on a foreign table results in the following error: Fail to access foreign data as user xxx, no token found in request header.

Since V2.2, MaxCompute foreign table operations have required authentication through a service-linked role (SLR). However, due to an implementation issue, users who had already created an SLR encountered an access failure when executing thehg_insert_overwrite, CREATE TABLE AS,

andCOPY commands.

Affected versions:

V2.2.1 to V2.2.14.

Fixed versions:

V2.2.15 and later.

Upgrade to the latest version.

P1

If a source table contains duplicate data, executing anUPDATE orUPSERT operation with deduplication based on the primary key may occasionally result in duplicate data in the target table, even if the table data TTL has not expired.

During anUPDATE orUPSERT operation, the target table and source table are joined. If the join keys of the two tables are different, the target table may be redistributed. In this scenario, if the source table has duplicate data, the optimizer may handle it incorrectly. This can lead to a deduplication failure and result in a duplicate primary key.

Affected versions:

V2.2.13 and earlier.

Fixed versions:

V2.2.14 and later.

Upgrade to the latest version.

P2

When using Flink to read data from Paimon and write it to Hologres, VARCHAR data can be written as garbled characters.

VARCHAR data in Paimon: Chinese characters
VARCHAR data in Hologres: ??? (garbled characters)

Hologres incorrectly converts Paimon VARCHAR data, causing garbled characters.

Affected versions:

V2.2.12 and earlier.

Fixed versions:

V2.2.13 and later.

Upgrade to the latest version.

P2

TheIS DISTINCT FROM syntax handles NaN data inconsistently with PostgreSQL.

--PostgreSQL behavior:
CREATE TABLE test_f8 (a float8);
INSERT INTO test_f8 VALUES ('NaN');
SELECT * FROM test_f8 WHERE a IS DISTINCT FROM 'NaN';
-- The following result is returned:
 a
---
(0 rows)
--------------------------------------------------------
--Hologres behavior:
CREATE TABLE test_f8 (a float8);
INSERT INTO test_f8 VALUES ('NaN');
SELECT * FROM test_f8 WHERE a IS DISTINCT FROM 'NaN';
-- The following result is returned:
  a  
-----
 NaN

To use an index, PostgreSQL defines comparison rules that treat NaN values as equal to each other and greater than any non-NaN value. However, Hologres follows the C++ standard comparison rules, where NaN values are not equal to each other. This discrepancy causes the results to be inconsistent with PostgreSQL.

Affected versions:

V2.1.37 and earlier.

Fixed versions:

• V2.1.38 and later.

• V2.2.10 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

Using Fixed Plan for a point query with multiple identical primary key conditions, such as select * from table_name where (pk=1) or (pk=1);, returns duplicate results.

Fixed Plan failed to deduplicate multiple filter conditions for the same primary key.

Affected versions:

V2.2.8 and earlier.

Fixed versions:

V2.2.9 and later.

• Do not include multiple filter conditions for the same primary key (pk) in the WHERE clause of a single SQL statement.

• Upgrade to the latest version.

P1

Performing a schema change during a rebalance can prevent the instance from processing writes and queries.

A rebalance triggers a switch between a shard's leader and follower if the replication delay is less than 10 seconds. If a user performs a schema change during this switch, the storage engine can enter an abnormal state. This prevents the instance from processing write and query operations. In Hologres V2.1, this issue is more likely because the system automatically triggers a rebalance when an instance has an empty worker node.

Affected versions:

• V2.1.16 to V2.1.23

• V2.0.0 to V2.0.41

Fixed versions:

• V2.1.24 and later

• V2.0.42 and later

Upgrade to the latest version.

P2

After you upgrade a Hologres instance to V2.1.25 or later, the system fails to automatically clean up temporary tables generated by an insert overwrite statement for tables in non-public schemas.

A detection oversight during the execution of an insert overwrite statement prevented the proper cleanup of temporary tables.

Affected versions:

V2.1.25 to V2.1.32.

Fixed versions:

V2.1.33 and later.

• Use the table management feature in HoloWeb to clean up temporary tables with one click.

• Upgrade to the latest version.

P2

When you use FixedFE (which corresponds to the jdbc_fixed mode in a connector) to write data to Hologres, FixedFE reports a permission denied for schema XXX error even though the SLPM model is enabled and the user has developer permission for the specified schema.

FixedFE failed to promptly refresh its cache when permissions changed in the SLPM model. As a result, FixedFE reported the error even though the user already had the required permissions.

Affected versions:

V2.0.31 and earlier

Fixed versions:

V2.0.32 and later.

Upgrade to the latest version.

Level

Description

Cause

Versions

Workaround

P2

When you use the datediff function to calculate the difference between two time values in a specified unit, the returned result is occasionally off by one.

The function contains a logic bug.

Affected version:

V2.0.31.

Fixed versions:

V2.1.27 and later.

Upgrade to the latest version.

P2

After a Hologres instance is upgraded to V2.1.26, the query memory usage metric shows a slow and continuous increase.

After the upgrade to V2.1.26, when a query encounters an OOM error, its memory usage is counted multiple times. This causes the corresponding monitoring metric to appear inflated.

Affected version:

V2.1.26.

Fixed versions:

V2.1.27 and later.

Upgrade to the latest version.

P1

After a Hologres instance is upgraded to V2.1, querying a MaxCompute foreign table may cause a gradual increase in memory usage, fluctuations in query performance, or an increase in OOM errors.

When you query a MaxCompute foreign table on a V2.1 instance, the system does not close open files promptly. This leads to a gradual increase in memory usage, which in turn affects query performance and instance stability.

Affected versions:

V2.1.1 to V2.1.25.

Fixed versions:

V2.1.26 and later.

Upgrade to the latest version.

P2

In V2.1, the storage usage of primary-secondary and virtual warehouse instances increases, where the total usage from monitoring metrics exceeds the value calculated by the pg_relation_size function.

The system does not promptly reclaim old files from V2.1 primary-secondary or virtual warehouse instances. This leads to storage growth and inflates the monitored storage amount.

Affected versions:

V2.1.1 to V2.1.25.

Fixed versions:

V2.1.26 and later.

Upgrade to the latest version.

P1

When a Flink job consumes the Hologres binary log in JDBC mode, the consumption rate is high at startup but then continuously decreases over time.

A memory leak occurs when a Flink job consumes the Hologres binary log in JDBC mode.

Affected versions:

VVR versions earlier than V6.0.7.

Fixed versions:

VVR V6.0.7 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P0

Query resources are not released, which leads to the following issues:

• Continuous memory increase.

• A large number of held locks.

• Numerous queries get stuck because they cannot allocate resources. Even after restarting the instance, the issue persists, and queries quickly become stuck again.

When a query involves only shard data and uses PQE or SQE to query a MaxCompute foreign table or a data lake foreign table, the system does not automatically release resources after the query completes. Only the garbage collection mechanism of the Query Master can reclaim these resources. When the Query Master is under heavy load, delayed exits cause query operations to hold excessive resources, blocking subsequent queries.

Affected versions:

V2.1.23 to V2.1.24.

Fixed versions:

V2.1.25 and later.

Upgrade to the latest version.

P1

Adding a bitmap to a dictionary-encoded, not-null column returns incorrect results, including null values.

When building a bitmap for a dictionary-encoded column, the backend fails to apply the bitmap to all data, which causes incorrect results.

Affected versions:

V2.1.21 and earlier.

Fixed versions:

V2.1.22 and later.

Upgrade to the latest version.

P1

Using Fixed Plan for real-time data writes or point queries causes the instance's memory usage to gradually increase.

In Hologres V2.1, the Fixed Plan execution engine was refactored. The operators it creates for read-write tables are not cleaned up promptly, which causes a memory leak.

Affected versions:

V2.1.1 to V2.1.9.

Fixed versions:

V2.1.10 and later.

Upgrade to the latest version.

P1

Canceling a query running on PQE may trigger a process deadlock on the corresponding PQE node, preventing it from handling new PQE requests.

Receiving a cancel signal can trigger a defect in the PQE I/O concurrency control feature. This issue affects all PQE processes.

Affected versions:

• V2.1.2 to V2.1.8.

• V2.0.23 to V2.0.30.

Fixed versions:

• V2.1.9 and later.

• V2.0.31 and later.

Upgrade to the latest version.

P2

The INTERSECT or EXCEPT function returns incorrect results when shard pruning is active. For example, when shard pruning is active, running the following example SQL may return an incorrect result.

SELECT * FROM (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1) 
a INTERSECT (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1);
  
--Incorrect result
user_id   
-------
 2
 
--Correct result
user_id   
-------
 1

The INTERSECT or EXCEPT function is currently implemented using JOIN. During shard pruning, the handling of these functions can generate an incorrect execution plan, resulting in incorrect query results.

Affected versions:

V2.1.21 and earlier.

Fixed versions:

V2.1.22 and later.

Upgrade to the latest version.

P2

When a PQE process exits, it may hang. This can accumulate over time and prevent PQE from handling new requests.

When a PQE process exits, a concurrency issue between the RPC exit thread and the main thread prevents the RPC exit thread from completing. This in turn prevents the PQE process from exiting cleanly.

Affected versions:

V2.1.0 to V2.1.14.

Fixed versions:

V2.1.15 and later.

Upgrade to the latest version.

P2

When concurrent queries are run on PQE, the instance may briefly restart.

In Hologres V2.0 and earlier versions, PQE has a multi-threaded concurrency issue that can cause a core dump in the instance.

Affected versions:

V2.0 and earlier.

Fixed versions:

V2.1.0 and later.

Upgrade to the latest version.

P2

When an SQL statement containing in ($1....) is executed in prepared statement mode and processed by the shard selector, the instance may briefly restart.

The optimizer generates an incorrect execution plan, which can cause a core dump in the instance.

Affected versions:

V2.0 and earlier.

Fixed versions:

V2.1.0 and later.

Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

Converting a TEXT type to a BIT type and then to a BIGINT type fails with the error: Cast FROM STRING to BINARY is not supported.. Example SQL:

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

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


--text to bit conversion fails with: Cast FROM STRING to BINARY is not supported.
--text to bit, then to bigint fails with: ERROR: syntax error at or near ")"

Incomplete support for converting the TEXT type to the BIT type causes the error: Cast FROM STRING to BINARY is not supported.. Subsequently, when converting to the BIGINT type, the system incorrectly identifies the BIT type, resulting in the error: syntax error at or near ")".

Affected versions:

V2.1.20 and earlier

Fixed versions:

V2.1.21 and later

Upgrade to the latest version.

P2

Setting the clustering key of a row-oriented table with a primary key to an empty string causes a metadata inconsistency and makes queries hang. Example table creation SQL:

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

If a row-oriented table's clustering key is an empty string and differs from its primary key, the FE node fails to respond to requests. This results in a metadata inconsistency and causes queries to hang.

Affected versions:

V2.1.20 and earlier

Fixed versions:

V2.1.21 and later

• Recreate the table and explicitly specify the clustering key. For optimal performance, we recommend that the clustering key and primary key of a row-oriented table match.

• Upgrade to the latest version.

P2

A query returns an incorrect result if its filter condition (WHERE clause) contains the clustering key and ORDER BY is also used to sort by that key. An example is a query like WHERE a >= xxx LIMIT x ORDER BY a, where the a column is the clustering key. Example SQL:

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

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

SELECT count(1) FROM (SELECT * FROM test3 WHERE a>=500  AND a <= 500 ORDER BY a ASC LIMIT 20 OFFSET 11440)a;
--An unexpected result is returned. The `LIMIT` is 20, but the query might return 30 rows.

When a filter condition contains a clustering key and ORDER BY is used to sort by that clustering key, the algorithm for the ORDER BY clause is matched incorrectly, which causes the returned results and the LIMIT results to be incorrect.

Affected versions:

V2.1.19 and earlier

Fixed versions:

V2.1.20 and later

Upgrade to the latest version.

P1

In Hologres V2.1, instance memory usage slowly increases, and queries on MaxCompute foreign tables occasionally fail with an ERPC_ERROR_CONNECTION_CLOSED error.

After an instance is upgraded to V2.1, it fails to promptly close the underlying data files of foreign tables. This causes a memory leak and occasionally triggers an instance restart.

Affected versions:

V2.1.10 to V2.1.18

Fixed versions:

V2.1.19 and later

Upgrade to the latest version.

P2

Multiplying DECIMAL type values produces a result with incorrect precision. Example SQL:

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

--Hologres result, incorrect
2.222222222000000000
1.111111111000000000
1.111111111000000000
2.222222222000000000

--PostgreSQL result, correct
1.111111111100000000
1.111111111200000000
2.222222222200000000
2.222222222400000000

The default decimal precision for DECIMAL type multiplication is 18. If the multiplication of two DECIMAL types produces a result with more than 18 decimal places, the system truncates the data before calculation, leading to an incorrect result.

Affected versions:

V2.1.18 and earlier

Fixed versions:

V2.1.19 and later

• Convert (CAST) the DECIMAL type values to the TEXT type.

• Upgrade to the latest version.

Level

Description

Cause

Affected and fixed versions

Workaround

P2

After upgrading to Hologres V2.1, executing an INSERT operation following a truncate operation occasionally results in an Invalid table id in schema error.

In Hologres V2.1, the FrontEnd component incorrectly set an excessively long replay cache time. This slowed DDL replay for DML operations following a DDL operation.

Affected versions:

V2.1.1 to V2.1.14.

Fixed versions:

V2.1.15 and later.

Upgrade to the latest version.

P2

The jsonb_to_textarray function does not support constant folding, causing SQL statements that involve constant calculations to fail with an ERROR: internal error: The left deepest leaf node of columnar access ref error. Example:

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

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

An incorrect pushdown occurs when the jsonb_to_textarray function is used with a constant in an SQL statement, which results in an error.

Affected versions:

• V2.1.1 to V2.1.14.

• V2.0.34 and earlier.

Fixed versions:

• V2.1.15 and later.

• V2.0.35 and later.

Upgrade to the latest version.

P2

Using the regexp_split_to_array function occasionally causes an ERROR: Illegal udf8 string in xxxx error.

The regexp_split_to_array function reads beyond its memory bounds, which causes the query to fail.

Affected versions:

V2.1.1 to V2.1.12.

Fixed versions:

V2.1.13 and later.

Upgrade to the latest version.

P2

Queries using SELECT * FROM <table_name> LIMIT xxx; can occasionally hang.

Hologres uses lazy loading for a full table scan with a LIMIT clause. The query hangs because the scan reads too much data at once.

Affected versions:

• V2.1.1 to V2.1.11.

• V2.0.33 and earlier.

Fixed versions:

• V2.1.12 and later.

• V2.0.34 and later.

Upgrade to the latest version.

P2

After an instance restart, upgrade, or scaling, MaxCompute tasks that directly read from Hologres foreign tables can occasionally hang.

After an instance restart, the system refreshes the table metadata. The task hangs because MaxCompute fails to retrieve the updated metadata status in time during a direct read.

Affected versions:

• V2.1.0 to V2.1.2.

• V2.0.5 and earlier.

Fixed versions:

• V2.1.3 and later.

• V2.0.26 and later.

Upgrade to the latest version.