關鍵缺陷通知

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P0

邏輯分區表更新部分主鍵時，flush資料可能導致執行個體重啟

邏輯分區表在更新主鍵情境存在缺陷

V3.1.1

V3.2.29、V3.1.43

升級到最新版本。

P0

資料寫入過程中報錯Partition count [65535] in memtable has exceed the limit [65535]後Worker重啟

記憶體表memtable分區數限制檢查存在缺陷，未正確統計本次待寫入分區數，導致Worker自殺

V4.0.1

V4.1.21、V4.2.2、V4.0.37

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P1

對開啟Binlog的表執行Rebuild時，有機率出現接入節點卡住，執行個體不可用

Rebuild底層在處理開啟Binlog的表時存在缺陷

V4.1.1

V4.1.21

• 升級到最新版本。

• 關閉GUC set hg_experimental_rebuild_try_to_using_dynamic_table_mode=off後執行Rebuild。

P2

串連執行個體時在options內設定多項配置會使得串連失敗或配置值錯誤。如串連時設定options為-c statement_timeout=1000 -c search_path=public，則串連失敗，報錯Connect to FE failed, invalid value for parameter "statement_timeout": "1000-csearch_path=public"

網關模組處理options欄位時錯誤地忽略了空格

• V2.0.18~V2.0.35

• V2.1.1~V2.1.15

• V2.0.36

• V2.1.16

• 升級到最新版本。

• 避免在串連options中設定超過一個配置。

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P2

使用資料脫敏 V2版本查詢含有脫敏表的VIEW時可能錯誤地出現permission denied for schema xxx或者permission denied for table xxx報錯資訊

資料脫敏對於許可權攔截錯誤導致報錯

• V4.0.1~V4.0.27

• V4.1.1~V4.1.12

• V4.0.28

• V4.1.13

升級到最新版本。

P1

建立了全域二級索引（Global Index）的表執行DML時，如果執行計畫使用Shard Prune運算元，會報錯Transaction xxxxxxxxxxxxx has no snapshot of table xxxxx index 1.

全域二級索引暫不支援處理Shard Prune運算元

V4.0.1

待修複

• 針對報錯Query，關閉GUC hg_experimental_enable_shard_pruning。

• 修複後升級到最新版本。

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P1

全文倒排索引的短語檢索模式時，如果設定slot參數大於255，檢索結果可能不正確。

全文倒排索引針對slot大於255時的匹配邏輯存在缺陷。

V4.0.1

V4.1.9

• 升級至最新版本。

• 避免設定slop>255。

P2

動態表incremental重新整理模式下，Volatile函數下接Agg且Volatile不在最後一列時，重新整理失敗。報錯：

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

distribution key list被帶到內層查詢，但distribution key list對應的是最終output column，與內層列無法對應。

V3.1

• V4.1.8

• V4.0.24

• 繞過方式：使用full mode，或將Volatile函數寫在distribution key後面。

• 升級至最新版本。

P2

載入Table Group到計算群組時，FE可能擷取不全SE shard location資訊，導致FixedFE寫入失敗，影響時間長度約1秒。

函數DDLReadService::DoGetTableGroupShards中碰到ShardInfos為空白時使用了break而非continue，導致資料擷取不全。

V1.1

• V4.1.7

• V4.0.24

• 升級至最新版本。

P2

當array列變長類型超過64MB時進行攢批，報錯Copy overflow with offset xx, length xx, and array length xx。

mutable array只reserve了一行，但append進來的array超過1行；當text列超過64MB時，builder大小被reserve成一行，沒有考慮到最小值。

V4.0

• V4.1.6

• V4.0.21

• 繞過方式：執行alter database xxx set hg_experimental_enable_batch_accumulator_v2=off;。

• 升級至最新版本。

P2

使用者執行SQL時阿里雲帳號名不能自動轉換為ID，如GRANT USAGE ON SCHEMA public TO "ALIYUN$a"。

is_initdb被錯誤地視為true，未聲明extern bool is_initdb;。

• V2.2

• V3.0

• V3.1

• V3.2

• V4.0

V3.0.53

• 繞過方式：避免使用帳號名，直接用ID做相關操作。

• 升級至最新版本。

P2

批量copy處理時共用記憶體可能寫滿，報錯ERROR: Parse data from copy ecountered internal error或coredump（棧中有holo_copy或CopyReadLineText）。

copy批量模式將用戶端資料按行數攢批寫入共用記憶體，使用者作業單條資料較大（每批約600MB），多串連同時寫入時可能將共用記憶體用滿，導致後續資料寫入失敗或讀取側因溢出讀取到非法值導致進程崩潰。

V1.1

• V4.1.5

• V4.0.21

• V3.2.31

• 繞過方式：採取流式copy寫入；或調小攢批條數hg_experimental_query_batch_size（預設8192），如alter user xx set hg_experimental_query_batch_size = 512;。

• 升級至最新版本。

P2

Parquet讀數組列時，因page index跳頁導致報錯。開啟page index（預設開啟），SQL讀數組列且有謂詞下推到parquet reader並因此有任意列的任意頁被過濾時可能觸發。

page index跳頁邏輯與數組列讀取存在相容性問題，當謂詞過濾導致頁跳過時，數組列的讀取狀態未能正確同步。

V3.1

• V4.1.5

• V4.0.19

• V3.2.29

• V3.1.43

• 繞過方式：關閉page index：set hg_experimental_enable_external_parquet_use_page_index = off;。

• 升級至最新版本。

P2

Fixed plan模式下，INSERT ON CONFLICT語句中WHERE條件為常量時結果不正確。執行insert into a values(0,1) on conflict(id) do update set id = excluded.id, name = excluded.name where 1 = 0;時，id不衝突但寫入0行。

當WHERE條件為常量運算式時，未能正確進行條件改寫，導致合格資料無法寫入。

V4.0

• V4.1.6

• V4.0.24

• 繞過方式：使用INSERT OR IGNORE文法，避免在ON CONFLICT運算式中使用常量條件。

• 升級至最新版本。

P2

Parquet reader無法處理空row group，讀到包含0行的row group時報錯，錯誤資訊被拋回使用者側。Hologres V3.1及以上版本可能表現為coredump，棧中包含hologram::spi::parquet::RowRange。

reader內部假設row group中一定包含資料（非0行），在處理空row group時，解析資料頁返回eof時被忽略，導致錯誤處理邏輯被觸發。

V3.0

• V4.1.4

• V4.0.19

• V3.2.29

• 繞過方式：用hiveqe執行query，設定GUC參數：set hg_experimental_force_access_dlf_paimon_via_hiveqe = on;或set hg_experimental_force_access_dlf_iceberg_via_hiveqe = on;或hg_experimental_enable_access_dlf_via_fse = off;。

• 升級至最新版本。

P0

bulkload提交空檔案導致flush失敗。bulkload提交了一個file size為0的檔案，導致後續的flush開啟這個檔案讀meta時失敗。

bulkload觸發deletion compaction時，被pick的檔案中所有行都被標記刪除，產生空檔案。

V3.1

• V4.1.2

• V4.0.18

• V3.2.29

• V3.1.43

• 繞過方式：設定GUC參數並重導表：set hg_serverless_computing_run_compaction_before_commit_bulk_load = off;。

• 升級至最新版本。

P2

二級索引包含bool類型時，Fixed plan寫入報錯。建立global index並insert時報錯：ERROR: XX000: internal error: unexpected error, failed to write, detail: Unsupported type in fixed dispatcher.

fixed dispatcher不支援bool類型在二級索引中的寫入。

V4.0.0

• V4.0.16

• V4.1.2

• 升級至最新版本。

P2

Holo FDW跨執行個體查詢失敗。升級4.0後使用外表查詢時報錯：Fetch table group shards failed on meta proxy:Loading cached shard location value for table group[...] failed。

FDW載入緩衝的shard location值時失敗。

V4.0.6

• V4.0.15

• V4.1.1

• 升級至最新版本。

P2

從脫敏表寫入資料到含自增列的目標表時出現非預期行為。在Hologres V4.0及以前版本，從脫敏表寫入到另一個表時，如果目標表存在自增列，會出現coredump或報錯行為異常。

代碼假設parsetree->targetList和rte_insert->insertedCols一一對應，但當目標表含有自增列時假設不成立。parsetree->targetList包含自增列和使用者明確寫入的列，而rte_insert->insertedCols只包含使用者明確寫入的列。

V3.1

• V3.2.26

• V4.0.14

• V3.1.42

• 繞過方式：不要使用自增列。

• 升級至最新版本。

P2

Array Ref介面線程不安全導致coredump。從Hologres V2.2開始，worker層級shuffle和QE v2的shuffle邏輯中，多線程訪問array->type時可能出現coredump，array的type欄位變為非法值。

ArrayRef的擷取type介面雖標記為const，但使用mutable關鍵字使成員變數type_可改。多線程同時擷取type時可能破壞type_的control block，導致安全執行緒問題。

V3.1

• V4.1.6

• V4.0.21

• V3.2.31

• V3.1.45

• 臨時繞過：關閉worker層級shuffle和QE v2。set hg_experimental_enable_worker_level_connection = off; set hg_experimental_enable_qe_v2 = off;。

• 升級至最新版本。

P2

已建立的Dynamic table執行alter definition加列時報錯。base表為物理分區表、DT為邏輯分區表時，對DT執行alter definition報錯：ERROR: New definition is not supported in incremental mode: Multiple partitions of table XXX is selected或ERROR: New definition is not supported in incremental mode: No partitions of table XXX is selected。

create流程中已關閉GUC忽略QO分區數檢查，但alter definition流程未同步該邏輯。

V3.1

• V3.1.40

• V3.2.24

• V4.0.12

• V4.0.13

• 繞過方式：設定GUC參數：set hg_experimental_check_selected_partition_table_number_for_dynamic_table = off;之後再執行alter definition。

• 升級至最新版本。

P2

建立External Dynamic table時報主鍵重複錯誤。當External DT的select query中join或union多個相同表時，產生的base table list包含重複項，插入系統資料表時報錯：ERROR: duplicate key value violates unique constraint "pg_holo_external_dynamic_table_dependencies_name_index"。

dt和external dt都存在該問題。dt的系統資料表沒有主鍵所以插入重複記錄未報錯，但external dt的系統資料表有主鍵約束，不允許插入重複記錄。

V4.0

V4.0.13

• 升級至最新版本。

P2

char(n)類型資料執行彙總查詢時報錯。開啟AQE後執行select col1, max(col2) from t1 group by col1時報錯：hos_exception: Internal error: HGERR_code XX000 ExecuteQuery failed, last errmsg: syntax error at or near "4294967291"。

ORCA中對於輸出結果為char類型的agg未推導type_modifier欄位，導致agg結果的char類型type_modifier被置為-5（即4294967291）。開啟AQE時嘗試建立char(4294967291)類型欄位，超出長度限制導致報錯。

V3.1

• V3.1.39

• V3.2.24

• V4.0.12

• V4.0.13

• 繞過方式：關閉AQE：alter database xxx set hg_experimental_enable_adaptive_execution = off;。

• 升級至最新版本。

P2

view中包含無別名子查詢時，snapshot SQL執行失敗。在view的select語句中使用了subquery alias optional功能（子查詢未指定別名）後，執行hg_dump_script產生的snapshot sql會報錯：unnamed_subquery不存在。

pg從view rule中推導view definition sql時未強制給subquery指定別名。當使用者的view中subquery alias未指定別名時，推匯出的view definition sql也沒有給subquery指定名字，但target list中卻指定了名字，導致sql解析失敗。

V4.0

• V4.1.6

• V4.0.12

• 繞過方式：使用者將這類view進行create or replace方式重建，給每個subquery都指定別名。

• 升級至最新版本。

P1

Paimon DV表按PK group後出現重複記錄。當Parquet檔案中存在物理格式為FIXED_LEN_BYTE_ARRAY、邏輯格式為decimal且編碼格式為plain的page，讀取該列的record batch跨越頁邊界時，僅該record batch中頁邊界之後的資料會被錯誤放置於record batch開始處。

Parquet decoder放置資料時未加上位移量，導致record batch跨越頁邊界時資料位元置錯誤。

V3.1.0

• V3.1.39

• V3.2.23

• V3.2.24

• V4.0.12

• 繞過方式：執行select hg_admin_command('set_global_flag', 'enable_create_decimal_array_v2 = true');。

• 升級至最新版本。

P2

MC表切換成Common Table鏈路後，Auto Analyze擷取不到表最新的last modified time資訊。使用者升級到Hologres V3.0.51後，查詢外表時從普通鏈路改成Common Table鏈路後，OOM報錯仍然存在。MC表三層模型情況下，common table鏈路擷取的response中schema name會變成default而非Holo的project_name，導致Auto Analyze批量擷取外表的last modified timestamp失敗，外表收集不到變化資訊。

common table鏈路與holo_native在三層模型處理上未對齊。fetcher->GetTables介面在三層模型情況下，holo_native返回的schema_name仍是project_name，但common table返回的schema_name會變成default，導致資料無法回填。

V3.0

• V3.0.52

• V3.1.39

• V3.2.23

• V3.2.24

• 繞過方式：手工執行ANALYZE。

• 升級至最新版本。

P2

Hologres使用CommonTable查詢MC資料的時候，oct_get_partition_names介面有緩慢的記憶體流失。Hologres V3.1.22升級到Hologres V3.1.30後出現，記憶體長期來看存在持續緩慢上漲的情況。開啟CommonTable對MC分區表進行高頻查詢時觸發。

oct_get_partition_names介面存在緩慢的記憶體流失，長期累積導致記憶體持續上漲。

V3.0

• V3.0.51

• V3.1.36

• V3.2.18

• V4.0.7

• 繞過方式：這個記憶體流失比較緩慢，當holo_worker記憶體較高的時候，可以重啟記憶體高的pod來恢複，如果pod比較多，可以重啟執行個體。

• 升級至最新版本。

P1

Union all在hash join的probe側，第一個孩子中hash join產生的runtime filter被推到第二個孩子中，導致查詢結果資料缺失。

Runtime filter經過映射下推到union all的第二個孩子過程中，合并了第一個孩子中的RF，導致錯誤下推。

V3.1

• V3.1.39

• V3.2.23

• V3.2.24

• V4.0.12

• 繞過方式：設定GUC參數：alter database set hg_experimental_enable_runtime_filter_push_thru_union_all=off;。

• 升級至最新版本。

P2

曾經rename過或alter schema過的dynamic table，升級到Hologres V4.0.7及以上版本，無法自動重新整理。報錯：ExecuteQuery failed, last errmsg: Can not find dynamic table properties of XXX或relation "XXX" does not exist。

dynamic table需要在driver中定期從FE擷取最新properties。代碼從table driver轉移到driver master時，漏掉了同步最新table name和schema name的代碼，導致升級後使用首次建立時的名稱無法重新整理。

V4.0.7

• V4.0.10

• V4.0.13

• 升級至最新版本。

P2

CTAS（Create Table As Select）在createstmt階段執行QO最佳化時，存在影響效能的最佳化步驟。

CTAS語句在createstmt階段走QO最佳化時，部分最佳化步驟不必要地影響了效能。

V4.0

• V4.0.10

• V4.0.13

• 升級至最新版本。

P1

增量重新整理的動態表使用ANY_VALUE函數彙總時計算結果不正確。基表欄位只有一個值，但查詢DT表出現多個值。

FinalizeStateRows時錯誤將result_array的產生放在迴圈體裡面，該bug未CP到3.2版本。

V3.2

V3.2.24

• 繞過方式：將該函數換成MIN/MAX函數，如select id, sum(col1), min(col2) from t1 group by id。

• 升級至最新版本。

P2

查詢外表時，從普通鏈路改成Common Table鏈路後，OOM報錯增多。報錯：ERROR: internal error: common table memory pool out of memory。

Common Table鏈路在Auto Analyze收集時許可權有變化，系統無法擷取表的last modified time，導致auto-analyze無法觸發，統計資訊未及時更新引發OOM。

• V3.0.42

• V3.1

• V3.2

• V4.0

• V4.0.9

• V3.1.38

• V3.2.21

• V3.0.51

• V3.2.24

• 繞過方式：手動執行ANALYZE。

• 升級至最新版本。

P2

Dynamic table refresh同時開啟多行事務時，走Serverless報錯。

Patch將TG不存在的報錯提前到FE檢查，但未考慮Serverless特殊情況。在Follower計算群組上執行無法自動路由的Serverless DML時會觸發。

V4.0

• V4.0.9

• V4.0.13

• 繞過方式：走DML自動路由（如賦予Leader計算群組許可權）；或串連Leader warehouse執行SQL或建立DT。

• 升級至最新版本。

P2

Query OOM（記憶體溢出）。

shuffle的ec優先順序被改低，導致CPU較滿時搶不到時間片，build端擷取資料較慢，runtime filter構建延遲，probe端讀取過多資料導致RF過濾效率降低。

V4.0.x之後

• V4.0.10

• V4.0.13

• 繞過方式：設定GUC參數：hg_experimental_enable_qe_v2 = on、hg_experimental_runtime_filter_wait_time_ms = 10000、hg_experimental_wait_for_all_runtime_filters = on。

• 升級至最新版本。

P1

部分登入審計日誌中client_addr欄位為空白。

Gateway彙報登入審計日誌時額外調用getpeername擷取用戶端IP，若此時用戶端串連已異常斷開則無法擷取。

支援登入審計日誌的所有版本

V4.0.13

• 升級至最新版本。

P2

使用preparestmt執行包含clustering key的查詢時報錯：ERROR: XX000: Dispatch query failed: internal error: DataType::STRING column range conjuncts should use string literal or parameter ref.

mask_md5是clustering key，在preparestmt時mask_md5 in (md5($1),md5($2))無法常量摺疊，導致提取的clustering filter中帶上了md5函數，後端無法解析該filter而報錯。

V1.1

• V3.1.37

• V3.2.20

• V4.0.8

• V3.2.24

• 繞過方式：不使用preparestmt；或將mask_md5 in (md5($1),md5($2))改為mask_md5 = md5($1) or mask_md5 = md5($2)。

• 升級至最新版本。

P2

使用者執行帶limit的query或主動cancel早停時，小機率發生coredump，導致query執行失敗，worker重啟。

SplitFactory的Close函數中進行了資源釋放操作，但沒有使用自己的ExecutionContext，導致資源釋放時機早於其他函數執行結束，引發coredump。

V3.2.4

• V4.0.7

• V3.2.19

• V3.2.24

• V4.0.13

• 繞過方式：設定GUC參數：alter role all set hg_experimental_enable_qe_v2 = off;。

• 升級至最新版本。

P2

TableGroup unload後Holoweb無法登入，元倉報錯ERROR: 42704: Table group[bizp.bizp_tg_default] is not found in warehouse bdmp_api_warehoue。Gateway指標顯示建立串連請求多、耗時高，短時間建立fixed fe串連數很多，消費binlog啟動時拿鎖時間久，並發多時會卡insert。

發生unload時，在舊的warehouse上的binlog/fixed plan等新請求在bhclient中會retry 27.5s。fixed fe上消費binlog是串連ec同步調用這個方法，當發生retry時會卡串連ec，導致fixed fe建立串連建立卡住，從而導致串連堆積。

V3.2

V4.0.8

• 繞過方式：停止binlog消費任務，改Flink作業使用正確的warehouse消費；或使用者側登入Holoweb把未載入的table group load到目標計算群組，如果Holoweb無法登入，需要找FE研發後台重啟gateway。

• 升級至最新版本。

P2

Hologres V3.1版本Dynamic Table開啟auto refresh後，容器記憶體（監控尺度拉到7天層級）持續上漲，holo worker記憶體穩定但FE記憶體升高。重複執行hg_generate_query_options_for_dynamic_table時記憶體持續上漲。

UDF hg_generate_query_options_for_dynamic_table存在記憶體流失。UDF中new了一個HoloQmDispatcher對象，雖然使用shared_ptr，但DispatcherManager會將其放入以query_id為key的map中。代碼建立的query_id不是UDF執行query的query_id，而是一個單獨的query_id。正常query結束時應調用RemoveDispatcher(query_id)刪除dispatcher，但代碼中漏了這一步。DispatcherManager生命週期與conn進程綁定，導致dispatcher對象不斷累積。

V3.1.0

• V4.0.0

• V3.1.26

• V3.2.8

• 繞過方式：在pg_stat_activity中找到並kill掉長串連；或註冊cron job自動清理超過1小時的串連：SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE length(query) > 0 AND pid != pg_backend_pid() AND backend_type = 'client backend' AND state = 'idle' AND application_name = 'DynamicTableTableDriver' AND current_timestamp - backend_start > '1 hour';。

• 升級至最新版本。

P2

執行個體中存在2個worker記憶體高於其他worker，且無shard傾斜。監控顯示FE記憶體差距過大，從記憶體開始上漲時間點查詢，存在長串連存活很久且執行了大量DDL（query_count > 1000）。

DDL執行流程中存在記憶體流失。QueryDesc對象的記憶體釋放依賴query結束時MemoryContext的整體釋放，但UtilityStmt（廣義DDL）的記憶體配置在長生命週期的MemoryContext中，導致query層級MemoryContext釋放時不會釋放它，產生記憶體流失。

所有版本

• V3.1.22

• V3.2.5

• V3.2.24

• 繞過方式：關閉存在記憶體流失的長串連即可釋放記憶體。可通過SQL排查：SELECT pid, session_id, count(*) as query_count, max(query_start) FROM meta_warehouse.query_info WHERE query_start > now() - '1 hour'::interval AND command_tag NOT IN ('INSERT','SELECT','DELETE','UPDATE') GROUP BY 1,2 ORDER BY 3 DESC LIMIT 20;。

• 升級至最新版本。

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P1

建立含有空格、特殊字元和大小寫複雜表名的表時，執行個體短暫重啟。

在從系統資料表擷取表的table property時狀態錯誤，導致執行個體coredump。

• V4.1.6

• V4.0.23

• V4.1.7

• V4.0.24

• 升級至最新版本。

P2

ai_gen與to_file聯用時會報錯。

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

ai_gen與to_file聯用時，類型轉換錯誤，導致函數報錯。

• V4.1.5

• V4.0.21

• V4.1.6

• V4.0.22

• 升級至最新版本。

P1

如果某計算群組沒有載入源表所在Table Group，在使用該計算群組通過輕量級串連模式（Flink源表參數connection.fixed.enabled為開啟或根據執行個體版本預設開啟狀態）消費源表Binlog後，該執行個體會持續無法建立串連。

在通過輕量級串連模式消費Binlog的初始化階段，由於當前計算群組未載入Table Group，請求會自動重試。重試期間錯誤持有全域鎖，導致無法響應建立串連。

• V3.1.13

• V3.2.10

• V4.0.0

• V4.0.8

• 升級至最新版本。

• 若執行個體串連數充裕，將源表connection.fixed.enabled設為false，臨時繞過此問題。

P1

含有雙流Join的增量動態表首次重新整理或REFRESH OVERWRITE時有機率報錯。

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

如果定義中有基於雙流Join結果的彙總，則可能導致彙總結果錯誤。

首次增量重新整理有小機率會將短時間內已經被刪除的資料計算進去，導致報錯或者結果錯誤。

• V3.2.5

• V4.0.1

• V4.1.1

• V4.0.21

• V4.1.6

• 升級至最新版本。

P2

array_to_string函數在處理兩個入參請求時，如果輸入資料包含NULL值，則該NULL值將參與計算。這與PostgreSQL的行為不一致，預期應為NULL值不參與計算。

HQE引擎在處理該函數兩個入參請求時，計算邏輯存在缺陷。

• V3.0.1

• V3.1.1

• V3.2.1

• V3.0.46

• V3.1.25

• V3.2.24

• 升級至最新版本。

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P2

在使用JOIN且執行引擎是PQE時，報錯

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

Join 和 PQE情境下，Join的輸出資料行和PQE的輸入列對不齊導致報錯。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.33

• V3.2.24

• V4.0.13

• 改寫SQL，避免使用PQE引擎執行。

• 升級至最新版本。

P2

使用了PQE引擎，執行了between計算，報錯

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

PQE引擎不支援between運算元計算。

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.13

升級至最新版本。

P1

將timestamp作為segment key或者cluster key時，進行過濾會導致最終結果沒有被過濾。

儲存引擎在當前提取segment key有問題，導致資料未過濾。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.24

• V4.0.13

升級至最新版本。

P1

升級到V4.0後記憶體持續升高，且在沒有任何查詢時也沒有下降和平穩的趨勢。

V4.0 版本在 result cache 鏈路遇到dict array會發生記憶體泄露。

• V4.0.0

• V4.0.10

• 關閉開關，臨時繞過該問題。

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

• 升級至最新版本。

P2

在CTE複用的情況下無法產生plan，報錯

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

由於QO未正確更新CTE計數，導致最終報錯。

• V3.2.0

• V4.0.0

• V3.2.24

• V4.0.7

• 關閉開關，臨時繞過該問題。

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

• 升級至最新版本。

P2

使用範圍方式取數組元素報錯，例如array_column[1:1]。

QO處理數組元素有問題，導致最終報錯。

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.13

升級至最新版本。

P1

同時滿足如下所有條件時，若Shard數大於bucket數，則PQE輸出的資料不經過shuffle直接和另外一張同個Table Group的表的普通列存scan的結果做JOIN、UNION ALL 計算，有機率漏資料。

• 列存表走主鍵索引，觸發 point seek

• 資料直接使用PQE計算

列存表使用主鍵索引的時候QO產生的計劃裡沒有使用Gather運算元，導致如果bucket數不等於shard數，一個bucket裡有多個shard，pqe query 計算的shard_count/bucket_count的機率漏資料。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.39

• V3.2.24

• V4.0.10

升級至最新版本。

P2

• 當使用者rebuild的表，表名含有大寫字母又沒有其他特殊字元時。rebuild報錯，任務失敗，progress裡顯示擷取view失敗。

• 當使用者rebuild的表，列名含有大寫字母又沒有其他特殊字元時。rebuild報錯，任務失敗，progress裡顯示暫存資料表缺列。

rebuild在老版本中並未考慮大小寫情況，所以導致失敗。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.40

• V3.2.25

• V4.0.13

升級至最新版本。

P2

subquery中包含case when運算式時，報錯如下：

ERROR: column "xxx" does not exist

查詢最佳化工具處理該情境時存在Bug，導致無法產生可用的查詢計劃。

• V3.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• V4.1.0

• V3.0.53

• V3.1.41

• V3.2.25

• V4.0.14

• 關閉開關，臨時繞過該問題。

  ALTER DATABASE <database_name> set hg_experimental_reuse_switch_case_expression =off;  

• 升級至最新版本。

P1

在Flink消費Hologres Binlog時，如果Flink作業中定義的源表（Source Table）僅包含Hologres物理表中的部分列，則消費的資料可能會出現非預期的空值。

Flink的Hologres Connector在處理消費Binlog部分列的情境時存在缺陷。

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

• Flink VVR 11.3及11.4版本的熱修複於2026年1月9日正式發布。

• 修複時間後重啟Flink作業即可。

• 修複前，可在Flink源表的WITH參數中增加如下配置並重啟作業：source.binlog.project-columns.enabled' = 'false'。

P1

已完成的Query可能未能正確清理，從而導致事務殘留，進而造成表鎖無法釋放。

目前的版本在部分已結束啟動並執行Query的記憶體回收(GC)邏輯上存在缺陷，導致查詢標識符（query_id）殘留。

• V2.2.0及以下版本。

• V3.0.0

• V2.2.32

• V3.0.12

• 升級至最新版本。

• 使用如下SQL手動清理殘留的query：

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

嚴重等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P0

查詢 DLF 的 Paimon Postpone 表時，會讀取到已提交但尚未進行壓縮的資料，從而導致主鍵表中出現主鍵重複的情況。

Hologres升級至V3.2.12版本後，Paimon SnapshotReader類的介面行為發生了變更：

• 舊版Paimon SDK：SnapshotReader在構造時，會自動為postpone表添加onlyReadRealBuckets選項。該選項確保唯讀取已完成Compaction的最終資料。

• 新版Paimon SDK：移除了上述自動添加邏輯。現在，使用者需要手動為SnapshotReader配置此選項，才能實現唯讀最終資料的行為。

• V3.2.12

• V4.0.0

• V3.2.24

• V4.0.11

• 升級至最新版本。

P1

在使用DLF外表時，當設定Paimon表的bucket_num=-2時，在涉及多表JOIN的情境中，由於產生的JOIN計劃不正確，導致資料未能關聯，從而造成查詢結果的不準確。

當設定Paimon表的bucket_num=-2時，在涉及多表JOIN的情境中，由於產生的JOIN Plan不正確，導致資料未能有效關聯，從而造成查詢結果不準確。

• V3.2.0

• V4.0.0

• V3.2.21

• V4.0.8

• 關閉開關，臨時繞過該問題，設定SQL如下：

  ALTER DATABASE <database_name> set hg_experimental_use_shard_info_in_hashed_dist_spec=off;  

• 升級至最新版本。

P1

在使用CTE運算式時，發現拆分執行與聯合執行的結果存在差異。

在使用CTE運算式時，儘管在執行中間結果時出現了失敗，但並未將該失敗情況上報給FE，最終導致了結果的錯誤。

• V3.2.0

• V4.0.0

• V3.2.17

• V4.0.6

• 升級至最新版本。

P1

在使用者具備相應許可權的前提下，holgores.hg_query_log 和 hologres.hg_table_info 的查詢結果為空白。

holgores.hg_query_log 和 hologres.hg_table_info 資料未上報。

• V2.0.39

• V2.2.16

• V3.0.0

• V2.0.47

• V2.1.44

• V2.2.24

• V3.0.2

• V3.1.0

• V3.2.0

• V4.0.0

• 升級至最新版本。

P0

含有多流JOIN 的 Dynamic Table增量重新整理時，當只有一條流有資料且資料有回撤時，重新整理結果出錯，結果和查詢結果不一致。

在Dynamic Table進行增量重新整理時，存在僅在單流回撤情況下未能正確處理的問題，導致應從結果表中刪除的資料未被正確移除，從而造成結果表的錯誤。

• V4.0.1

• V4.0.9

• 首先對錶資料進行修改，然後使用 refresh overwrite 修正已出現錯誤的資料，具體操作如下所示的兩個 SQL：

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

• 升級至最新版本。

P1

升級至V4.0版本後，出現了Worker OOM錯誤，相關報錯資訊類似：

1. 報錯：ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

2. 報錯：ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

為了在記憶體中緩衝更多資料，V4.0版本對記憶體結構進行了最佳化。然而，新的記憶體結構在處理Decimal類型時存在缺陷，因此當包含Decimal列的表參與HashJoin時，可能會導致執行個體發生CoreDump。

• V4.0.0

V4.0.10

• 關閉查詢記憶體最佳化，臨時繞過該問題，SQL設定如下：

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

• 升級至最新版本。

P1

查詢 MaxCompute Append Delta Table 有資料的表時，查詢返回為空白。

受到 Split Cache 影響，導致查詢結果為空白。

• V4.0.0

V4.0.9

• 關閉 Split Cache，臨時繞過該問題。

ALTER DATABASE <database_name> set hg_experimental_enable_maxcompute_sdk_splits_cache=off;

• 升級至最新版本。

P0

在V4.0版本中使用邏輯分區表，邏輯分區表包含主鍵並設定了clustering_key時，發現有主鍵資料重複。

V4.0 版本為了最佳化邏輯分區表的寫入效能，支援多分區 Flush，在多分區 Flush 時，Cluster Index 的處理邏輯存在 Bug，導致寫到Apsara Distributed File System上的 AliORC 檔案（列存內表的資料檔案）內部的 Cluster Index可能有錯，Cluster Index 錯誤可能導致資料存在但查不出來，最終導致在寫入更新情境下，可能會認為不存在老資料，直接寫了一條新的，從而產生重複。

• V4.0.0

V4.0.9

• 升級至最新版本。升級至最新版本後，增加了對於錯誤檔案的檢測邏輯，如果掃描到寫錯的檔案，報錯如下clustered_index size [x] incorrect。此時需要你對報錯的表執行 Full Compaction操作修複檔案。更多說明請參見分區表常見問題。

P1

升級到V4.0版本後，出現Worker OOM 報錯，報錯資訊類似。報錯1：ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

報錯2：ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

為了能夠在記憶體中緩衝更多的資料，V4.0 版本最佳化了記憶體結構，新的記憶體結構對於資料大小計算不準，導致過小的預估了需要放進記憶體的資料，最終導致了記憶體不夠引起了worker OOM。

• V4.0.0

V4.0.7

• 關閉 Result Cache，臨時繞過該問題。

ALTER DATABASE <database_name> set hg_experimental_enable_result_cache=off;

• 升級至最新版本。

等級

報錯/問題描述

缺陷原因

出現版本

修複版本

規避建議

P1

在Flink即時寫入情境中，drop目前使用者，後在建立同名的有許可權的使用者，即使建立串連，仍然報錯沒有許可權。

FixedFE組件使用者權限緩衝更新策略問題。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.21

• V4.0.9

• 升級至最新版本。

P1

Dynamic Table 使用 Stream 模式增量重新整理資料時，對 base 表做insert/update/delete，立刻truncate或insert overwrite，再次重新整理時，重新整理資料不正確。

Dynamic Table 使用 Stream 模式增量重新整理資料時，對 base 表做insert/update/delete，立刻truncate或insert overwrite，再次重新整理時，同一個主鍵可能消費到重複的delete訊息，導致Dynamic Table結果不正確。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升級至最新版本。

P2

通用型執行個體執行SELECT hg_rebalance_instance()進行rebalance時報 shard group not found的錯誤。

通用型執行個體rebalance預設傳參錯誤，導致報錯。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升級至最新版本。

P2

擴縮過程中，在 Table Group 的 Leader 計算群組和 Follower 計算群組目前會很低機率遇到 ShardPermissionDenied的報錯，導致秒級的寫入失敗。

擴縮過程中，在 Table Group 的 Leader 計算群組和 Follower 計算群組目時預期會捕捉失敗，並重試，但是ShardPermissionDenied的報錯，沒有轉為可重試的 kShardHotMigrationInProgress，導致報錯到使用者端

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 升級至最新版本。

P2

訪問 MaxCompute 鏈路切換到 Common Table 鏈路後，當 Dynamic Table 使用了 MaxCompute 外表時，重新整理報錯，報錯資訊如下：

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

Dynamic Table傳遞plan的方式和普通olap query不同，傳遞過程中傳遞的binary被寫壞了，導致filter解析失敗。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.36

• V3.2.17

• V4.0.6

• 關閉 Common Table 訪問鏈路，臨時繞過該問題。

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

• 升級至最新版本。

P2

使用專家許可權模型時，在使用者被賦予 Dynamic Table 的 Owner 許可權後，使用Dynamic Table的Owner身份對歷史表或者分區重新整理時，仍報錯Permission Denied。

因為重新整理的身份時首次重新整理緩衝下來的，導致修改許可權身份後報錯。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.0

• V3.2.0

• V4.0.0

• 升級至最新版本。

P2

查詢DLF的資料時，對timestamp列的進行range filter查詢時報錯，報錯資訊如下：

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

literal類型錯誤處理錯誤，錯誤的使用了long進行處理

• V3.2.0

• V4.0.0

• V3.1.17

• V4.0.6

• 關閉 Bigmeta 訪問鏈路，臨時繞過該問題。

ALTER DATABASE <database_name> set hg_experimental_enable_big_meta=off;

• 升級至最新版本。

P2

當主鍵中包含boolean類型的列，且DML插入資料少於10條時，報錯，報錯資訊如下：

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

Query Engine會把boolean類型的array轉化為uint8 array，hybrid dml在建立row group filter時未考慮這個情境，導致row group filter裡literal的類型（bool）和實際的實值型別（long）不匹配。

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.7

• 關閉hybrid dml，臨時繞過該問題。

ALTER DATABASE <database_name> set hg_experimental_enable_hybrid_dml = off;

• 升級至最新版本。

P2

使用Remote UDF 時，報錯如下：

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

調用時多執行緒存在問題，導致最終報錯。

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.8

• 升級至最新版本。

P1

Dynamic Table 使用 Stream 模式增量重新整理資料時，若 base 表 compaction 後立刻 refresh，可能會導致增量資料亂序。

因為同一個key消費到的增量是亂序的，會導致最終的sink表結果錯誤。

• V3.1.0

• V3.2.0

• V3.1.23

• V3.2.6

• 升級至最新版本。

P1

針對Rebuild功能：

• 未開啟Binlog模式：將物理分區表Rebuild成邏輯分區表時，最終的邏輯分區表會錯誤地開啟Binlog。

• 開啟Binlog模式：物理分區表Rebuild成邏輯分區表時，最終的邏輯分區表未開啟Binlog。

rebuild partition to logical partition操作時，對Binlog的處理邏輯存在錯誤。

• V3.1.1

• V3.2.1

• V4.0.1

暫未修複

P2

使用create table as讀的是DLF外表，報錯如下：

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

create table as在讀取DLF V2.0的表時，許可權讀取錯誤。

• V3.0.1-V3.0.49

• V3.1.1-V3.1.34

• V3.2.1-V3.2.16

• V4.0.1-V4.0.4

• V3.0.50

• V3.1.35

• V3.2.17

• V4.0.6

• 升級至最新版本，並改用Rebuild功能。

P2

源表使用了資料脫敏，當使用create table as語句時，報錯the insert table has not set security label。樣本 SQL 如下：

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

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

資料脫敏的設定沒有傳遞到create table as過程中，導致報錯。

• V3.1.1-V3.1.32

• V3.2.1-V3.2.12

• V4.0.1-V4.0.2

• V3.1.33

• V3.2.13

• V4.0.3

• 升級至最新版本，並改用Rebuild功能。

P0

使用者使用array高階函數時，如果返回結果數組裡面的元素都是相同的，則有可能去重為只有一個元素的數組。樣本SQL：

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

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

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

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

數組計算架構對所有元素相同的數組處理存在缺陷。

• V3.2.1-V3.2.16

• V4.0.1-V4.0.5

• V3.2.17

• V4.0.6

• 升級至最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P0

使用 HoloWeb 的 Table Resharding 功能時，若任務異常並點擊“取消任務”，發現系統未正確清理暫存資料表。
此時手動執行 DROP TABLE 刪除該暫存資料表，會導致 Frontend（FE）卡住，無法響應。

HoloWeb內部整合的清理函數存在缺陷

出現版本：

• V2.0.24

修複版本：

• V2.2.28

升級至最新版本。

P2

HG_MOVE_TABLE_TO_TABLE_GROUP（即Resharding）的目標表，如果表名帶有特殊字元，或表名本身為關鍵字，Resharding 會失敗（不報錯，但是操作後Table Group沒有變化）。

HG_MOVE_TABLE_TO_TABLE_GROUP在需要轉義的場合處理存在問題

出現版本：所有版本

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

升級至最新版本，並改用Rebuild功能。

P2

Hologres Serverless Computing計算資源後付費賬單中，“執行個體ID”欄位錯誤展示為<instance_id>_<uid>_<region_id>，預期應展示為<instance_id>

底層配置存在問題。

出現版本：所有版本。時間範圍為2025-09-09 16:00:00至2025-10-14 16:00:00。

修複版本：所有版本。時間範圍為2025-10-14 16:00:00後的賬單。

單獨處理錯誤時間段內的賬單。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P0

在系統執行Shard Rebalance（如擴縮容、重啟）過程中，若多條請求同時完成，可能導致後台進程異常，進而引發執行個體讀寫失敗。

幕後處理同時執行完成的多條請求時存在缺陷。

出現版本：V3.0.9版本。

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

升級至最新版本。

P0

Hologres外部表格資料匯入至內部表時，自適應調整匯入速度的功能在同時滿足以下條件時會造成資料丟失：

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

• 系統資源緊張導致匯入作業自動調整匯入速度。此時，如果外部讀取走到SQE鏈路，可能會導致少量資料片段遺漏，從而造成部分資料丟失。

外部表格資料匯入至內部表的自適應調整匯入速度功能，遇到外部表格資料讀取回退到SQE鏈路時，會導致部分資料丟失。

出現版本：

• V3.0.1~V3.0.46版本。

• V3.1.1~V3.1.27版本。

• V3.2.1~V3.2.9版本。

修複版本：

• V3.0.47及以上版本。

• V3.1.28及以上版本。

• V3.2.10及以上版本。

執行個體層級執行GUC關閉自適應匯入功能。

ALTER ROLE ALL SET hg_experimental_enable_adaptive_adjust_bulkload_dop = off;

P1

設定資料脫敏後，對錶執行update，查出來的結果沒有脫敏。樣本sql：

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

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

設定脫敏後，update對脫敏欄位處理錯誤，導致結果未脫敏。

出現版本：

• V3.1.0-V3.1.31

修複版本：

• V3.1.32

升級至最新版本。

P1

執行個體重啟後導致dynamic table不再自動重新整理。

後端調度系統異常導致。

出現版本：

• V3.0.0-V3.0.45

• V3.1.0-V3.1.24

• V3.2.0-V3.2.7

修複版本：

• V3.0.46

• V3.1.25

• V3.2.7

• V4.0.0

升級至最新版本。

P1

邏輯分區Dynamic Table，開啟自動重新整理後，活躍分區是增量重新整理模式，當分區結束活躍時間時，仍然為增量重新整理沒有自動轉為全量重新整理，且儲存不斷增加。

系統在處理dynamic table活躍分區時，分區狀態處理錯誤。

出現版本：

• V3.1.0-V3.1.23

• V3.2.0-V3.2.6

修複版本：

• V3.1.24

• V3.2.7

升級至最新版本。

P2

dynamic table設定clustering key，且是nullable屬性，在執行alter dynamic table時報錯clustering_key should not be nullable。

alter dynamic table時未能正常推導clusteringkey的屬性，導致報錯。

出現版本：

• V3.1.0-V3.1.31

• V3.2.0-V3.2.11

修複版本：

• V3.1.32

• V3.2.12

升級至最新版本。

P2

列存表不設定clustering key，使用insert on conflict do update離線匯入後，再即時寫入，會有機率出現重複pk。

離線寫入時處理主鍵的資料有誤，導致即時寫入沒有檢測到有重複資料，導致最後機率性出現主鍵重複。

出現版本：

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

修複版本：

• V3.1.30

• V3.2.10

• V4.0.2

升級至最新版本。

P2

insert on conflict有主鍵重複時設定了hg_experimental_affect_row_multiple_times_keep_last參數也有主鍵重複報錯duplicate key value violates unique constraint。

資料重複時，keep last的guc設定沒有生效導致仍然主鍵重複報錯。

出現版本：

• V3.1.0-V3.1.29

• V3.2.0-V3.2.9

• V4.0.0-V4.0.1

修複版本：

• V3.1.30

• V3.2.10

• V4.0.2

升級至最新版本。

P2

升級到V3.1版本後查詢含脫敏欄位的視圖報錯relation "xxx" does not exist。

V3.1版本的資料脫敏在處理視圖時，對視圖中的表名處理錯誤，導致報錯表不存在。

出現版本：

• V3.1.0-V3.1.22

• V3.2.0-V3.2.5

修複版本：

• V3.1.23

• V3.2.6

升級至最新版本。

P2

使用hg_insert_overwrite + external database 讀取相關外表時，有機率sql卡住。

hg_insert_overwrite處理external database相關表時訪問逾時，導致卡住。

出現版本：

• V3.1.0-V3.1.21

• V3.2.0-V3.2.4

修複版本：

• V3.1.22

• V3.2.5

升級至最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

當Query請求出現以下任一情況時，可能在Query結束時觸發Worker卡住問題，進而導致後續對相關表的DDL操作以及有LIMIT的Query請求被阻塞：

• Query請求發生記憶體溢出（OOM）。

• Query請求被手動取消。

• Query請求被手動Cancel或因異常結束。

查詢引擎在Query結束時的資源清理過程存在缺陷。

出現版本：

• V3.1.18版本。

• V3.2.3版本。

修複版本：

• V3.1.21及以上版本。

• V3.2.5及以上版本。

• 升級至最新版本

• 發生卡住時重啟執行個體或計算群組。

• 執行如下命令關閉新版查詢引擎。

  ALTER ROLE ALL SET hg_experimental_enable_qe_v2=off;

P1

使用Holo Client V2.6.0版本，通過阿里雲AccessKey（阿里雲帳號、RAM使用者、RAM角色）串連Hologres執行個體時，在每天的某個時間段內會串連失敗。串連失敗的時間段與使用Holo Client的用戶端時區有關，如東八區為00:00:00+08至08:00:00+08無法串連、西五區為19:00:00-05至00:00:00-05無法串連。

Holo Client V2.6.0版本對時區處理存在問題。

Holo Client V2.6.0版本（與Hologres執行個體無關）。

將Holo Client升級至V2.6.1及以上版本。

P0

在Hologres V3.1版本中，若執行個體建立了Dynamic Table並以Stream方式消費基表資料，當Dynamic Table處於唯讀（ReadOnly）狀態時，可能導致執行個體不斷重啟。

該情境會導致資料Flush失敗，從而觸發執行個體不斷重啟。

出現版本：

• V3.1.1~V3.1.20版本。

• V3.2.1~V3.2.2版本。

修複版本：

• V3.1.21及以上版本。

• V3.2.3及以上版本。

升級至最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

使用Serverless Computing匯入資料執行失敗時，中間檔案有機率未刪除，導致執行個體儲存量增加。

中間檔案清理邏輯有機率失效。

出現版本：V3.1.1版本。

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

• 重啟執行個體，清理中間檔案。

• 升級至最新版本。

P2

使用DLF查詢Iceberg的外部表格資料時，結果為空白，未返回任何資料。

查Iceberg時檔案解析錯誤，導致查詢為空白。

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

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

升級至最新版本。

P2

使用產生列建表，查詢錯誤ERROR: ORCA failed to produce a plan : Query Translation: No variable entry found due to incorrect normalization of query。樣本SQL如下。

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

CREATE VIEW v1 AS SELECT * FROM lpt1;

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

表中有產生列，發起查詢時，最佳化器翻譯產生列錯誤，導致查詢報錯。

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

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

升級至最新版本。

P1

建立Dynamic Table時，Query中有BOOLEAN類型，Refresh報錯： ERROR: Internal error: HGERR_code XX000 HGERR_msge can not get pg type string %s: id: UINT8。

Dynamic Table對於BOOLEAN類型的欄位推導錯誤，導致Refresh錯誤。

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

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

升級至最新版本。

P2

Hologres升級到V3.1版本後，hg_dynamic_table_state_size函數查詢結果為空白。

hg_dynamic_table_state_size未適配V3.1版本。

出現版本：

• V3.1.1~V3.1.15版本。

• V3.2.0~V3.2.1版本。

修複版本：

• V3.1.16及以上版本。

• V3.2.2及以上版本。

升級至最新版本。

P2

Hologres V3.1版本建立Dynamic Table為增量重新整理後，直接刪除Dynamic Table，狀態表仍然保留。

直接刪除增量重新整理的Dynamic Table時，狀態表沒有被正確清理，導致殘留。

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

修複版本：V3.1.13版本。

升級至最新版本。

P2

跨Schema使用rb_or_cardinality_agg等RoaringBitmap64位函數時，報錯：Unsupported agg function:public.rb_or_cardinality_agg。

RoaringBitmap64位相關函數的Schema推導錯誤，導致跨Schema查詢報錯。

出現版本：

• V3.1.1~V3.1.11版本。

• V3.2.0版本。

修複版本：

• V3.1.12及以上版本。

• V3.2.1及以上版本。

升級至最新版本。

P2

建立Dynamic Table為邏輯分區表時，Base表指定了欄位為NOT NULL，建立時報錯：failed:the index xx "xxx" should not by nullable。

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

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

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

Dynamic Table得NOT NULL屬性推導錯誤。

出現版本：

• V3.1.1~V3.1.11版本。

• V3.2.0版本。

修複版本：

• V3.1.12及以上版本。

• V3.2.1及以上版本。

升級至最新版本。

P2

單表物化視圖存在SUM(DECIMAL)時，執行個體會出現短暫重啟現象。

單表物化視圖計算SUM(DECIMAL)時，由於記憶體未對齊，導致執行個體發生了核心轉儲（coredump）

出現版本：

• V3.1.1~V3.1.17版本。

• V3.0.41~V3.0.43版本。

• V3.2.0~V3.2.1版本。

修複版本：

• V3.1.17及以上版本。

• V3.0.44及以上版本。

• V3.2.2及以上版本。

升級至最新版本。

P1

Hologres執行個體升級至V3.0.41版本後，使用CommonTable鏈路查MaxCompute外部表格時，記憶體緩慢上漲。

CommonTable鏈路查MaxCompute外表時，有記憶體泄露，導致記憶體上漲。

出現版本：

• V3.1.1~V3.1.17版本。

• V3.0.41~V3.0.43版本。

• V3.2.0~V3.2.1版本。

修複版本：

• V3.1.17及以上版本。

• V3.0.44及以上版本。

• V3.2.2及以上版本。

升級至最新版本。

P0

在特定並發情境下，對同一張表使用Serverless Computing執行DML操作時，同時執行TRUNCATE/DROP TABLE操作，可能因引擎內部狀態同步問題，導致該表所在Shard出現讀寫異常。

由於引擎並發處理存在問題，引起Shard內部狀態異常，受影響的Shard將暫時無法提供讀寫服務，可能影響業務中部分表的正常訪問。

出現版本：

• V2.1.45及以下版本。

• V2.2.45及以下版本。

修複版本：

• V2.1.46版本。

• V2.2.46版本。

• V3.0.27及以上版本。

• V3.1.1及以上版本

• 臨時方式：

  • 錯峰執行DML和TRUNCATE/DROP TABLE操作。

  • 不使用Serverless Computing執行 DML。

• 推薦方式：

  升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

計算群組執行個體擴容時，計算節點偶發性重啟。

系統缺陷，如果表同時存在DML任務、Compaction任務，並執行計算群組擴容時，有機率觸發。

出現版本：V3.0.1版本。

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

升級到最新版本。

P1

JSONB列式儲存最佳化和GIN索引一起使用時，執行個體會異常重啟。

JSONB列式儲存最佳化和GIN索引存在不相容情況。

出現版本：V3.1.1版本。

修複版本：

• V3.0.42及以上版本。

• V3.1.10及以上版本。

• 刪除表的GIN索引。

• 升級到最新版本。

P2

Dynamic Table的基表都是View時，執行Refresh會導致執行個體重啟。

當基表是View時，會導致Dynamic Table在Refresh時處理錯誤，導致執行個體coredump。

出現版本：V3.1.8版本。

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

升級到最新版本。

P2

Dynamic Table增量重新整理模式下，Query中有ARRAY_AGG函數，當資料全被Agg Filter過濾後，返回結果是空（期望是null）。

無。

出現版本：

• V3.0.40版本。

• V3.1.7版本。

修複版本

• V3.0.41及以上版本

• V3.1.7及以上版本

升級到最新版本。

P1

屬性關聯漏鬥函數（finder_funnel）指定時區時，結果計算錯誤。指定時區的樣本SQL如下：

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

finder_funnel函數預設是UTC時區，當在SQL中指定時區時，將時區錯誤的丟棄，導致結果錯誤。

出現版本：V3.0.40版本。

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

升級到最新版本。

P2

計算群組執行個體，使用PG_RELATION_SIZE、PG_DATABASE_SIZE、HOLOGRES.HG_RELATION_SIZE查出來的儲存不正確。

計算群組執行個體下，使用PG_RELATION_SIZE查詢出來的儲存會多算，導致結果不正確。

出現版本：V3.0.39版本。

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

升級到最新版本。

P2

Dynamic Table增量重新整理模式下單次重新整理時，如果基表中有多行重複的資料，重新整理報錯ERROR: internal error: Filter has 1 rows but length of columns。

當單次重新整理有多行重複資料時，增量重新整理處理錯誤導致重新整理報錯。

出現版本：V3.0.39版本。

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

升級到最新版本。

P2

Dynamic Table增量重新整理有多表JOIN時，表中有ARRAY欄位的Refresh報錯XX000: internal error: Not Implements。

有ARRAY欄位時，多表JOIN的增量重新整理無法正確處理。

出現版本：

• V3.0.38版本。

• V3.1.2版本。

修複版本

• V3.0.39及以上版本

• V3.1.3及以上版本

升級到最新版本。

P1

通過事務向邏輯分區寫入資料時，如果分區列資料基數過大導致分區數量超過限制（5200個），則事務Commit時，會發生執行個體重啟。

事務Commit時檢查到邏輯分區表的分區數超出限制，進程異常自行終止，導致執行個體Coredump。

出現版本：V3.1.1版本。

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

最佳化匯入任務的資料品質，清洗分區鍵的髒資料，避免分區數量過多。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

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

在讀取MaxCompute外表時介面轉換錯誤，導致讀取外表失敗。

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

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

升級到最新版本。

P2

hg_create_table_like複製表coment時發生錯誤。

hg_create_table_like在複製表comment時識別錯誤，將表comment複製成了列comment。

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

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

升級到最新版本。

P2

查詢資料湖外表時報錯ERROR: failed to get foreign table split from hive:Failed to generate splits: IllegalStateException: Weights must be non-negative。

讀取外表時，資料格式轉換錯誤，導致報錯。

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

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

升級到最新版本。

P1

使用ARRAY_AGG函數後，機率性出現記憶體持續上漲的情況。

ARRAY_AGG函數存在記憶體泄露問題，導致記憶體使用量量持續增加。

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

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

升級到最新版本。

P2

CTE查詢語句中存在Nested Loop Join時，報錯Cannot open a fragment with explicit_seek set to false。

最佳化器推導JOIN ORDER錯誤，導致查詢報錯。

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

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

升級到最新版本。

P2

使用GENERATE_SERIES函數處理DECIMAL類型的欄位時，報錯generate series first and second arguments should has same type。

最佳化器對DECIMAL類型欄位的精度推導錯誤，導致報錯。

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

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

升級到最新版本。

P2

查看hg_stat_activity的query_id欄位，當engine_type={PG}時，query_id的內容不準確。

當engine_type={PG}時，hg_stat_activity彙報query_id錯亂，導致query_id不準確。

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

使用視窗函數，例如ROW_NUMBER() OVER，處理欄位lc_state_split_idx時，報錯ORCA failed to produce a plan。

視窗函數處理lc_state_split_idx欄位時，將其誤識別成了關鍵字，導致錯誤的截斷，從而無法產生執行計畫，最終引發SQL報錯。

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

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

升級到最新版本。

P1

在Dynamic Table中手動指定Distribution Key時，不生效。

引擎推導錯誤，導致手動設定的Distribution Key未生效。

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

用BI或開發工具串連Hologres時，沒有許可權的使用者也能看到Database、Schema和Table的中繼資料資訊。

許可權控制不嚴格。

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

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

升級到最新版本。

P2

MaxCompute外部表格JOIN Hologres_fdw外部表格時查詢報錯error: Build desc failed: Fetch table group shards failed on meta proxy。

Hologres_fdw外部表格在JOIN MaxCompute外部表格時，如果內部表發生Shard Pruning，會產生邏輯錯誤，導致查詢報錯。

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

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

升級到最新版本。

P2

Hologres執行個體升級到V2.2版本後，使用GENERATE_SERIES集合返回函數處理DECIMAL類型欄位時報錯error: generate series first and second arguments should has same type。

GENERATE_SERIES函數處理DECIMAL欄位時，最佳化器對DECIMAL類型的欄位精度推導錯誤，導致查詢報錯。

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

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

升級到最新版本。

P2

為某個帳號設定脫敏規則為all:unmasked，但是未脫敏的情況並未生效，查出來的資料仍然是脫敏。

設定脫敏後，沒有正確判斷帳號的脫敏規則導致查詢不符合預期。

出現版本：

• V3.0.1及以下版本。

• V2.2.21及以下版本。

修複版本：

• V3.0.2及以上版本。

• V2.2.22及以上版本。

升級到最新版本。

P2

使用JDBC模式消費Hologres Binlog時，作業拋出Binlog Convert Failed、Java heap space等異常，或部分Shard的資料讀取在某個時刻停止，無法繼續消費。

在消費Binlog的過程中，如果Flink下遊運算元反壓或其他異常，導致源表資料消費不及時，後端會拋出逾時異常。Gateway轉寄異常到客戶過程中存在問題，導致讀取數據卡住或資料解析失敗報錯。

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

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

升級到最新版本，並重啟Flink任務。

P2

JSONB列在開啟列式儲存最佳化功能後，如果設定了Bitmap索引，將會導致資料寫入後Flush和Compaction失敗，執行個體儲存量上漲、記憶體水位上升。

JSONB列式儲存最佳化功能對BINARY類型開啟Bitmap索引的處理存在缺陷。

出現版本：

• V3.0.1~V3.0.9版本。

• V2.2.31及以下版本。

修複版本：

• V3.0.10及以上版本。

• V2.2.32及以上版本。

• 升級到最新版本。

• 關閉該表的列式儲存最佳化功能，並重建該表。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

array_agg函數在視窗裡的計算結果錯誤。樣本如下：

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

--正確的結果
a	array_agg
0103	{3}
0102	{3,2}
0101	{3,2,1}

array_agg函數與視窗函數一起計算時，計算邏輯錯誤導致結果不正確。

出現版本：

• V3.0.1~V3.0.21版本。

• V2.2.38及以下版本。

修複版本：

• V3.0.22及以上版本。

• V2.2.39及以上版本。

升級到最新版本。

P2

建立EXTERNAL TABLE時，含有大寫字元的表，查詢報錯：

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

EXTERNAL TABLE在讀取包含大寫字元的表時，大小寫轉義錯誤，導致查詢報錯。

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

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

升級到最新版本。

P2

未配置OSS Endpoint時，查詢DLF中的表報錯：

SELECT * FROM openlake_demo_dlf.github_events.ods_github_events_raw;

--報錯資訊
ERROR: internal error: external dataset reader missing required oss_endpoint option.

未配置OSS Endpoint時，無法正確路由到對應的OSS表，導致查詢報錯。

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

Dynamic Table在全量和增量重新整理時，若包含DECIMAL類型欄位，將報錯column type doesn't match, decimal(28, 10) v.s. decimal(38, 10)。

Dynamic Table在全量和增量重新整理時，DECIMAL類型欄位的精度推導錯誤，從而導致Refresh報錯。

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

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

• 手動指定Query中DECIMAL類型欄位的精度。

• 升級到最新版本。

P2

UNION ALL兩邊Query Schema不一致時報錯schema's field number from producers are not equal [1 vs 0]。

UNION ALL推導Schema不正確，從而導致報錯。

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

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

升級到最新版本。

P2

Dynamic Table增量重新整理對SMALLINT類型欄位進行彙總時，報錯不支援。

Dynamic Table增量重新整理對SMALLINT類型支援不夠完善。

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

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

升級至最新版本。

P2

升配計算群組執行個體後，查詢報錯CreateFile ignore since it's not leader。

升配計算群組期間，表Meta未及時更新，導致查詢時擷取的是舊錶Meta的資料，從而導致升配後報錯。

出現版本：

• V3.0.12~V3.0.15版本。

• V2.0.35及以下版本。

修複版本：

• V3.0.16及以上版本。

• V2.2.36及以上版本。

• 重啟升配的計算群組。

• 升級到最新版本。

p1

Hologres升級至V3.0.12～V3.0.15版本後，對於開啟動態分區的表，如果分區鍵類型是TEXT，動態分區的調度可能會出現錯誤，從而導致建立分區表失敗。

對於TEXT為分區鍵時，調度系統處理有問題，會導致內部轉換失敗，從而建表失敗。

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

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

升級到最新版本。

p1

Hologres版本升級至V3.0~V3.0.13版本後，查詢MaxCompute外表效能變慢。

自Hologres V3.0版本，加強了擷取MaxCompute Table Meta許可權檢查，這導致FE節點發生多次反覆調用，從而降低了查詢MaxCompute外部表格的效能。

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

Dynamic Table全量重新整理模式下開啟Binlog後，Refresh報錯ERROR: internal error: refresh table failed: internal error: new_values is missing col。

Dynamic Table全量重新整理模式下開啟Binlog後，隱藏列推導不一致，導致Refresh報錯。

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

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

升級到最新版本。

P2

SLPM許可權模型下，刪除Orafce Extension再重新建立會報錯“role slpm xxx already exists“。

SLPM許可權模型下，刪除Orafce Extension時使用者組的許可權未清理乾淨，導致在重新建立時使用者組仍然存在，從而無法成功建立Orafce Extension。

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

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

• SLPM改成專家許可權模型後再重新建立Orafce Extension。

• 升級到最新版本。

P2

Dynamic Table中有Decimal欄位，Refresh時報錯invalid definition of a numeric type。

Decimal欄位的精度推導不正確，導致Dynamic Table在Refresh時精度不一致而報錯。

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

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

• 建立Dynamic Table時手動指定Decimal欄位的精度。

• 升級到最新版本。

P2

元倉大於10 s的Query偶發出現Plan列沒有EXPLAIN ANALYZE結果。

大於10 s的Query在彙報偶發延遲，導致Plan列沒有採集到結果。

出現版本：

• V3.0.8及以下版本。

• V2.2.33及以下版本。

修複版本：

• V3.0.9及以上版本。

• V2.2.34及以下版本。

升級到最新版本。

P2

Analyze帶BIS類型的表報錯Not supported type: bsi0.] in cache failed。

Analyze對BIS類型的欄位支援不完善，導致出現報錯。

出現版本：

• V3.0.8及以下版本。

• V2.2.31及以下版本。

修複版本：

• V3.0.10及以上版本。

• V2.2.32及以上版本。

升級到最新版本。

P2

使用hg_insert_overwrite後，產生的暫存資料表未自動清理。

hg_insert_overwrite過程中因清理機制未啟動，導致暫存資料表未清理。

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

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

升級到最新版本。

P2

執行個體頻繁執行DDL操作，若FE節點的版本剛好不一致時執行了TRUNCATE操作，此時對TRUNCATE執行CANCEL時，無法成功CANCEL，可能會導致資料結果不一致。

當FE節點的版本不一致時，會出現節點Relay卡住，導致後續DDL失敗，如果期間執行DROP、TRUNCATE，執行CANCEL不會成功。

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

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

升級到最新版本。

P2

執行SQL語句過長超出了限制報錯：ERROR: Current query length xxx exceeds the limit 10000000。

Hologres增加了SQL長度限制，預設值10000000。

出現版本：

• V2.2.22及以上版本。

• V3.0.1及以上版本。

通過設定如下參數取消SQL長度限制。

ALTER DATABASE db_name SET hg_experimental_query_length_limit = 0;

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

資料庫首次開啟DML事務後，如果在SQL中對同一表執行並發DDL操作，可能會導致Query卡住等現象。

在資料庫首次使用DML事務時，將首先擷取表鎖。如果該表存在並發的DDL操作，系統將進入嘗試建表的迴圈，機率性出現死結，導致Query卡住等。

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

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

升級到最新版本。

P2

對於包含roaringbitmap類型欄位的Hologres表，當通過CREATE FOREIGN TABLE命令建立Hologres跨庫查詢外表，且外表中不包含roaringbitmap類型欄位時，可成功建立外表，但在使用SELECT * FROM方式查詢包含roaringbitmap類型的欄位時，報錯cache lookup failed for type 22243。

跨庫查詢的外表不支援roaringbitmap類型，在建立外表時需要校正。

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

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

升級到最新版本。

P2

使用JDBC prepareStatement方法時，反覆執行CREATE EXTENSION命令後報錯unrecognized extension: "PostgreSQL JDBC Driver"，而使用其他工具則未發現此問題。範例程式碼如下：

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

使用JDBC prepareStatement方法迴圈執行CREATE EXTENSION命令後，導致Cache被破壞，從而出現報錯。

出現版本：

• V2.2.23及以下版本。

• V3.0.3及以下版本。

修複版本：

• V2.2.24及以上版本。

• V3.0.4及以上版本。

• 一個資料庫只需要執行一次CREATE EXTENSION，無需反覆執行。

• 升級到最新版本。

P2

元倉Query Log中的result_rows和affected_rows值與實際值不符。

元倉彙報result_rows和affected_rows時發生錯誤，導致彙報的值與實際值不符。

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

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

升級到最新版本。

P2

計算群組執行個體中，重啟主計算群組時，可能會導致從計算群組點查（基於主鍵的查詢）變慢。

重啟主計算群組時，正常啟動並執行計算群組對應的Shard會輪詢主Shard狀態，導致點查卡住，直到所有Shard恢複後才會繼續執行。

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

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

升級到最新版本。

P2

BSI_SUM函數結果數組中，所有元素的總和超出2^31時，結果出錯。

函數資料溢出情況誤處理。

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

修複版本：等待修複。

• 修複後升級到最新版本。

• 改寫SQL，樣本如下：

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

P2

串連Hologres執行個體偶發建立連線逾時或卡住，導致無法建立串連。

串連執行個體偶發節點內進程卡住，導致此節點無法建立新串連。

出現版本：低於V2.2.23，V2.1.43，V2.0.46，V1.3.71的版本。

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

• 短期方案：重啟執行個體可暫時解決。

• 長期方案：升級至各版本的最新小版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

計算群組執行個體中，若某個計算群組A不可用（如正在重啟），其他計算群組對A載入的Table Group中的表執行點查時，延遲升高。

即時讀寫鏈路內部模組存在缺陷，計算群組執行點查時會等待Table Group狀態，導致延遲升高。

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

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

升級到最新版本。

P1

Fixed Plan即時寫入資料量超過100萬QPS時，有小機率觸發寫入失敗和執行個體重啟。

即時讀寫鏈路記憶體管理器存在缺陷。

出現版本：

• V2.0.1~V2.0.43版本。

• V2.1.1~V2.1.36版本。

• V2.2.1~V2.2.8版本。

修複版本：

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

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

使用jdbc或jdbc_fixed模式讀取Hologres的Binlog時，如果Flink作業遭遇反壓導致後端逾時，有機率導致Flink作業卡住或觸發Failover。

Gateway收到後端逾時的異常資訊時，將異常返回給用戶端的過程中存在問題，導致讀取數據卡住或資料解析失敗報錯。

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

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

從最新的checkpoint直接重啟作業，並升級到最新版本。

P2

在V2.2版本之後，使用了Shard Pruning（執行計畫中包含Shard Prune運算元）的COUNT DISTINCT操作，通過PQE執行，導致計算效能下降。

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

使用Shard Pruning後，COUNT DISTINCT的執行計畫推導錯誤，導致通過PQE執行，影響查詢效能。

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

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

• 升級到最新版本。

• 將COUNTDISTINCT替換為UNIQ。

P2

慢Query日誌（query_log表）中query_start欄位的日期格式為2024-07-08 22:00:00，而query_date欄位日期格式為19700101。

慢Query日誌中的query_date欄位資料擷取錯誤。

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

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

升級到最新版本。

P2

在寫入分區子表時，若COPY列中包含了分區列，並且當分區值為0時，傳入其他非0值也能正常寫入，這可能導致分區值出現髒資料。

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

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

# 輸入
1,0
null,0
\.

在寫入分區子表時，如果copy列中包含了分區列，並且分區值為0，系統缺少對分區值為0的檢查，從而導致髒資料成功寫入。

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

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

升級到最新版本。

P2

在串連串上顯示的設定時區為SET timezone='+8'，且Query中含有PQE日期函數，例如to_char。執行結果將為西八區的日期（應為東八區）。樣本：

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

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

串連串上指定了時區後，PQE在解析日期函數時計算時區錯誤，導致結果錯誤。

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

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

升級到最新版本。

P2

使用pad_sub_cost函數時報錯Column should be non-nullable but the values contain 609 nulls。

pad_sub_cost函數在計算時Nullable屬性推導錯誤，導致查詢報錯。

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

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

升級到最新版本。

P0

使用動態分區管理功能時，如果time_unit設定為MONTH，即按月建立動態分區，則可能會誤建立未來分區、誤刪除當前分區。

自V2.2版本開始，動態分區管理功能支援自訂調度開始時間，對於按月分區時間計算有誤。

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

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

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P1

執行hg_insert_overwrite、CREATE TABLE AS

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

自V2.2版本開始，MaxCompute外部表格操作需要通過服務關聯角色（SLR）來進行身分識別驗證。由於當前實現存在問題，已建立SLR的使用者在執行hg_insert_overwrite、CREATE TABLE AS

和COPY命令操作時會遇到外部表格訪問失敗的情況。

出現版本：

V2.2.1至V2.2.14版本。

修複版本：

V2.2.15及以上版本。

升級到最新版本。

P1

源表存在重複資料，執行UPDATE或UPSERT並基於PK去重，目標表將偶發出現重複資料，且表資料TTL沒有到期。

執行UPDATE或UPSERT時，是目標表和源表JOIN，如果兩個表的JOIN KEY不一致，目標表會出現Redistribution。這種情況下，如果源表有重複資料，會導致最佳化器在處理重複資料時邏輯錯誤，資料未能正常去重，導致最後主鍵重複。

出現版本：

V2.2.13及以下版本。

修複版本：

V2.2.14及以上版本。

升級到最新版本。

p2

通過Flink將Paimon資料讀取並寫入Hologres時，Paimon VARCHAR類型資料與Hologres資料格式不一致。

Paimon中VARCHAR類型的資料：中國
寫入Hologres後的VARCHAR類型的資料為：？？？（亂碼）

Hologres對Paimon VARCHAR類型的資料轉換錯誤，導致出現亂碼。

出現版本：

V2.2.12及以下版本。

修複版本：

V2.2.13及以上版本。

升級到最新版本。

p2

IS DISTINCT FROM文法，對NaN資料處理和PostgreSQL不一致。

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

為了能夠利用索引，PostgreSQL定義了NaN和其他數位大小比較規則，將NaN值視為相等，且大於任何非NaN值。而Hologres在實現時遵循了C++標準的比較規則，因此NaN值互不相等，導致結果與PostgreSQL不一致。

出現版本：

V2.1.37及以下版本。

修複版本：

• V2.1.38及以上版本。

• V2.2.10及以上版本。

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

使用Fixed Plan點查多個相同主索引值時（例如select * from table_name where (pk=1) or (pk=1);），會返回多條相同結果。

Fixed Plan沒有對相同主鍵的多組過濾條件進行去重。

出現版本：

V2.2.8及以下版本。

修複版本：

V2.2.9及以上版本。

• 避免一個SQL語句的where過濾條件中存在多組相同主鍵（pk）值。

• 升級到最新版本。

P1

在Rebalance過程中，執行Schema Change的相關操作後，執行個體無法正常寫入和查詢。

在Rebalance過程中，當Shard的Leader和Follower延遲小於10秒時，將進行Follower和Leader的切換。在切換時，若使用者執行Schema Change的相關操作，會導致儲存引擎SE的狀態異常，進而導致執行個體無法進行正常的寫入和查詢操作。特別是在Hologres V2.1版本中，當執行個體存在空Worker節點時，會自動觸發Rebalance機制，從而增加了該問題發生的機率。

出現版本：

• V2.1.16至V2.1.23版本。

• V2.0.0至V2.0.41版本。

修複版本：

• V2.1.24及以上版本。

• V2.0.42以上版本。

升級到最新版本。

P2

Hologres執行個體升級至V2.1.25及以上版本後，對非public下的表執行insert overwrite語句時，產生的暫存資料表未能自動清理。

對insert overwrite語句，在執行時檢測疏漏，導致暫存資料表未能正常清理掉。

出現版本：

V2.1.25至V2.1.32版本。

修複版本：

V2.1.33及以上版本。

• 使用HoloWeb表管理功能，一鍵清理暫存資料表。

• 升級到最新版本。

P2

使用FixedFE（對應Connector中的jdbc_fixed模式）寫入資料到Hologres過程中，開啟SLPM模型並授予使用者對應Schema的開發人員（developer）許可權，但FixedFE出現報錯permission denied for schema XXX。

FixedFE在SLPM模型許可權變化時，沒有及時重新整理緩衝，導致使用者已有許可權，卻仍然出現相關報錯。

出現版本：

V2.0.31及以下版本

修複版本：

V2.0.32及以上版本。

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

使用datediff函數按照指定的單位計算兩個時間差值時，偶發返回結果與實際結果相差1。

該Function Compute存在邏輯缺陷。

出現版本：

V2.0.31版本。

修複版本：

V2.1.27及以上版本。

升級到最新版本。

P2

Hologres執行個體升級至V2.1.26版本後，監控指標顯示執行個體記憶體分布使用率中的Query記憶體緩慢上漲。

升級至V2.1.26版本，當Query出現OOM問題後，記憶體指標會被重複統計，導致監控中記憶體相關的指標上漲。

出現版本：

V2.1.26版本。

修複版本：

V2.1.27及以上版本。

升級到最新版本。

P1

Hologres執行個體升級至V2.1版本，且在執行個體中進行MaxCompute外部表格查詢時，出現執行個體記憶體緩慢上漲現象，Query效能出現抖動，或者OOM較多。

使用V2.1版本執行個體查詢MaxCompute外部表格時，開啟的檔案未被及時關閉，導致記憶體緩慢上漲，影響了Query效能或者執行個體穩定性。

出現版本：

V2.1.1至V2.1.25版本。

修複版本：

V2.1.26及以上版本。

升級到最新版本。

P2

V2.1版本中，主從執行個體或計算群組執行個體的儲存容量變多，表現為監控指標的儲存使用總量大於通過pg_relation_sizeFunction Compute的儲存總量。

V2.1版本的主從執行個體或計算群組執行個體回收舊檔案不及時，導致儲存容量增長，監控採集的儲存量變多。

出現版本：

V2.1.1至V2.1.25版本。

修複版本：

V2.1.26及以上版本。

升級到最新版本。

P1

Flink通過JDBC模式消費Hologres Binlog時，出現作業啟動時消費速率較高，之後持續下降的情況。

Flink通過JDBC模式消費Hologres Binlog時，存在記憶體流失問題。

出現版本：

VVR V6.0.7以下版本。

修複版本：

VVR V6.0.7及以上版本。

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P0

由於查詢資源未釋放導致：

• 記憶體持續上漲。

• 大量鎖佔用。

• 大量查詢因為分配不到資源導致卡住，即使重啟執行個體，也無法明顯緩解，在短時間內，仍會卡住。

當查詢僅涉及Shard資料，且使用了PQE或SQE執行MaxCompute外部表格或資料湖外部表格的查詢時，查詢完成後不會系統主動觸發資源回收，只能使用Query Master的記憶體回收機制來回收資源。當Query Master壓力較大時，查詢操作會因退出延遲而佔用大量資源，導致後續的查詢無法執行。

出現版本：

V2.1.23至V2.1.24版本。

修複版本：

V2.1.25及以上版本。

升級到最新版本。

P1

對字典編碼過的列添加bitmap，導致not null的列查詢結果錯誤，出現null值。

對字典編碼過的列添加bitmap，後端構建bitmap時，未對全部資料生效，導致結果有錯誤。

出現版本：

V2.1.21及以下版本。

修複版本：

V2.1.22及以上版本。

升級到最新版本。

P1

通過Fixed Plan進行資料的即時寫入或點查，執行個體記憶體使用量率逐漸上漲。

Hologres V2.1版本中Fixed Plan執行引擎進行了重構，其為讀寫表建立的operator沒有及時清理，導致記憶體泄露。

出現版本：

V2.1.1至V2.1.9版本。

修複版本：

V2.1.10及以上版本。

升級到最新版本。

P1

對運行在PQE上的Query執行取消（cancel）操作時，有機率觸發對應PQE節點的進程死結，無法處理新的PQE請求。

PQE IO並發控制功能缺陷，當PQE接收到cancel訊號時有機率觸發。影響所有PQE進程。

出現版本：

• V2.1.2至V2.1.8版本。

• V2.0.23至V2.0.30版本。

修複版本：

• V2.1.9及以上版本。

• V2.0.31及以上版本。

升級到最新版本。

P2

INTERSECT或EXCEPT函數在Shard Pruning時，出現執行結果與實際結果不一致。例如在Shard Pruning時，執行如下樣本SQL，返回結果可能與實際結果不符。

SELECT * FROM (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1) 
a INTERSECT (
	SELECT user_id FROM dc_ads_public_label_r where label_id = 1 and user_id = 1);
  
--返回結果，不正確
user_id   
-------
 2
 
--實際結果，正確
user_id   
-------
 1

當前INTERSECT或EXCEPT函數是通過JOIN實現，在Shard Pruning時，對於INTERSECT或EXCEPT函數的處理導致執行計畫不正確，結果出現錯誤。

出現版本：

V2.1.21及以下版本。

修複版本：

V2.1.22及以上版本。

升級到最新版本。

P2

在PQE進程退出時，存在小機率的卡死現象，持續積累後會導致PQE無法處理新的請求。

PQE進程退出時，啟動的RPC退出線程和主線程存在並發問題，導致RPC退出線程無法正常結束，進而導致PQE進程無法順利退出。

出現版本：

V2.1.0至V2.1.14版本。

修複版本：

V2.1.15及以上版本。

升級到最新版本。

P2

並發執行PQE的Query時，執行個體出現短暫重啟現象。

Hologres V2.0及以下版本中，PQE存在多線程並發問題，導致執行個體機率性的出現Coredump。

出現版本：

V2.0及以下版本。

修複版本：

V2.1.0及以上版本。

升級到最新版本。

P2

使用Prepared Statement模式執行包含in ($1....)的SQL，並經過分區選取器（shard selector）進行處理時，出現了執行個體短暫重啟現象。

最佳化器產生Plan錯誤，導致執行個體出現Coredump。

出現版本：

V2.0及以下版本。

修複版本：

V2.1.0及以上版本。

升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

TEXT類型先轉換為BIT類型，再轉換成BIGINT類型報錯：Cast FROM STRING to BINARY is not supported.。樣本SQL：

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

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


--text轉bit報錯不支援 ：Cast FROM STRING to BINARY is not supported.
--text轉bit，再轉bigint報錯 ：ERROR: syntax error at or near ")"

TEXT類型轉BIT類型支援不完善，導致出現報錯：Cast FROM STRING to BINARY is not supported.。然後BIT類型再轉BIGINT類型會錯誤識別BIT類型，出現報錯：syntax error at or near ")"。

出現版本：

V2.1.20及以下版本。

修複版本：

V2.1.21及以上版本。

升級到最新版本。

P2

行存表指定了PK，Clustering Key設定為空白串時，出現中繼資料不一致導致Query卡住。樣本建表SQL：

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

行存表的Clustering Key為空白串時，與PK不一致，FE節點響應請求失敗，從而造成中繼資料不一致，導致Query停滯。

出現版本：

V2.1.20及以下版本。

修複版本：

V2.1.21及以上版本。

• 重建立表，並顯式指定Clustering Key（建議行存表Clustering Key和PK一致，才能發揮更好的效能）。

• 升級到最新版本。

P2

Query的過濾條件（where）中包含Clustering Key，且使用Order By對Clustering Key排序，如where a >= xxx limit x order by a，a列是Clustering Key，Query計算結果不正確。樣本SQL：

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

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

SELECT count(1) FROM (SELECT * FROM test3 WHERE a>=500  AND a <= 500 ORDER BY a ASC LIMIT 20 OFFSET 11440)a;
--出現結果異常，limit 20，但是返回的資料可能是30

當過濾條件中有Clustering Key，且使用Order By對Clustering Key排序，會導致Order By的演算法匹配錯誤，從而出現返回的結果與LIMIT的結果不正確。

出現版本：

V2.1.19及以下版本。

修複版本：

V2.1.20及以上版本。

升級到最新版本。

P1

在Hologres V2.1版本中，執行個體記憶體使用量率有緩慢上漲，查詢MaxCompute外部表格時，偶發出現ERPC_ERROR_CONNECTION_CLOSED報錯。

執行個體升級到 V2.1版本後，由於外部表格的底層資料檔案沒被及時關閉，導致記憶體流失，偶發引起執行個體重啟。

出現版本：

V2.1.10至V2.1.18版本。

修複版本：

V2.1.19及以上版本。

升級到最新版本。

P2

DECIMAL類型相乘後精度不符合預期。樣本SQL：

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

--Hologres結果，不正確
2.222222222000000000
1.111111111000000000
1.111111111000000000
2.222222222000000000

--PG結果，正確
2.222222222000000000
1.111111111000000000
1.111111111000000000
2.222222224000000000

DECIMAL類型乘法預設小數精度是18位，兩個DECIMAL類型相乘後小數位元超過18時，會導致將資料截斷再計算，從而出現結果不符合預期。

出現版本：

V2.1.18及以下版本。

修複版本：

V2.1.19及以上版本。

• 將DECIMAL類型轉換（CAST）為TEXT類型。

• 升級到最新版本。

等級

報錯/問題描述

缺陷原因

出現/修複版本

規避建議

P2

升級到Hologres V2.1版本後，truncate後再執行INSERT操作會偶發報錯：Invalid table id in schema。

Hologres V2.1版本FrontEnd錯誤增加了過長的replay緩衝時間，導致同一個DDL後再執行DML，DDL replay會變慢。

出現版本：

V2.1.1至V2.1.14版本。

修複版本：

V2.1.15及以上版本。

升級到最新版本。

P2

jsonb_to_textarray函數不支援常量摺疊導致SQL帶有常量計算時會報錯：ERROR: internal error: The left deepest leaf node of columnar access ref。樣本SQL：

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

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

在SQL中jsonb_to_textarrayFunction Compute有常量時下推錯誤，從而出現報錯。

出現版本：

• V2.1.1至V2.1.14版本。

• V2.0.34及以下版本。

修複版本：

• V2.1.15及以上版本。

• V2.0.35及以上版本。

升級到最新版本。

P2

使用regexp_split_to_array函數偶發報錯：ERROR：Illegel udf8 string in xxxx。

regexp_split_to_array函數越界讀取到非預期的記憶體位址，導致查詢失敗。

出現版本：

V2.1.1至V2.1.12版本。

修複版本：

V2.1.13及以上版本。

升級到最新版本。

P2

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

對於全表掃描帶LIMIT的情境，Hologres會通過惰性載入（lazy loading）的方式載入資料，一次性掃描太多資料導致卡住。

出現版本：

• V2.1.1至V2.1.11版本。

• V2.0.33及以下版本。

修複版本：

• V2.1.12及以上版本。

• V2.0.34及以上版本。

升級到最新版本。

P2

對執行個體執行重啟、升級、升降配等涉及執行個體重啟的操作後，MaxCompute直讀Hologres外部表格時，偶發任務卡住。

對於Hologres表，後台會定期觸發中繼資料更新，執行個體重啟後，系統會重新重新整理一次表的中繼資料，MaxCompute直讀Hologres未能及時擷取中繼資料狀態，導致任務卡住。

出現版本：

• V2.1.0至V2.1.2版本。

• V2.0.5及以下版本。

修複版本：

• V2.1.3及以上版本。

• V2.0.26及以上版本。

升級到最新版本。