Hologres:注目すべき修正内容

重大度レベル

説明

根本原因

影響を受けたバージョン

修正済みバージョン

回避策

P0

主キーの一部が更新される論理パーティションテーブルでデータフラッシュを行うと、インスタンスが再起動する可能性があります。

フラッシュ操作中に、論理パーティションテーブルが主キー更新シナリオを処理する方法に不具合があります。

V3.1.1

V3.2.29、V3.1.43

修正済みバージョンにアップグレードします。

P0

Partition count [65535] in memtable has exceed the limit [65535] というエラーでデータ書き込みが失敗し、ワーカーが再起動します。

memtable のパーティション数検証に不具合があり、現在の書き込みバッチからのパーティションがカウントされないため、ワーカーが予期せず終了します。

V4.0.1

V4.1.21、V4.2.2、V4.0.37

重大度レベル

説明

根本原因

影響を受けたバージョン

修正済みバージョン

回避策

P1

Binlog が有効になっているテーブルで Rebuild を実行すると、フロントノードがハングし、インスタンスが利用できなくなる可能性があります。

Binlog が有効になっているテーブルを Rebuild する際の処理に不具合があり、ロック競合が発生してフロントノードがハングします。

V4.1.1 ～ V4.1.20

V4.1.21

• 修正済みバージョンにアップグレードします。

• Rebuild を実行する前に、GUC パラメーター set hg_experimental_rebuild_try_to_using_dynamic_table_mode=off を無効にします。

P2

接続文字列で複数のオプションを指定すると、接続が失敗するか、パラメーター値が正しくなくなります。たとえば、options を -c statement_timeout=1000 -c search_path=public に設定すると、次のエラーが発生します。Connect to FE failed, invalid value for parameter "statement_timeout": "1000-csearch_path=public"

ゲートウェイモジュールが options フィールドを解析する際に、空白文字を誤って削除するため、複数のパラメーターが 1 つの不正な値に結合されます。

• V2.0.18 ～ V2.0.35

• V2.1.1 ～ V2.1.15

• V2.0.36

• V2.1.16

• 修正済みバージョンにアップグレードします。

• 接続オプション文字列に複数のオプションを指定しないでください。

重大度レベル

説明

根本原因

影響を受けたバージョン

修正済みバージョン

回避策

P2

Data Masking 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

修正予定

• クエリエラーを解決するには、GUC パラメーター hg_experimental_enable_shard_pruning を無効にしてください。

• 修正済みバージョンがリリースされたら、アップグレードしてください。

重大度

説明

根本原因

影響を受けたバージョン

修正済みバージョン

回避策

P1

全文転置インデックスのフレーズ検索モードで、slop パラメーターが 255 を超えると、不正確な検索結果が生成される場合があります。

slop 値が 255 より大きい場合、全文転置インデックスのマッチングロジックに不具合があります。

V4.0.1

V4.1.9

• 最新バージョンにアップグレードします。

• slop パラメーターに 255 より大きい値を設定しないでください。

P2

dynamic table の更新が incremental refresh mode で失敗します。これは、Volatile 関数が集計関数の前にあり、最後の列にない場合に発生します。エラーは次のとおりです。

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

分散キーのリストが内部クエリに渡されますが、これは最終的な出力列に対応しており、内部クエリの列にマッピングできません。

V3.1

• V4.1.8

• V4.0.24

• 完全モードを使用するか、Volatile 関数を分散キーの後に配置します。

• 最新バージョンにアップグレードします。

P2

virtual warehouse にテーブルグループをロードする際、FE (Frontend) が SE (Storage Engine) からシャードの場所情報を完全に取得できない場合があり、FixedFE 書き込み操作が約 1 秒間失敗します。

関数 DDLReadService::DoGetTableGroupShards で、ShardInfos が空の場合に break が使用され、continue が使用されなかったため、データ取得が不完全になります。

V1.1

• V4.1.7

• V4.0.24

• 最新バージョンにアップグレードします。

P2

可変長データ型を持つ配列列を 64 MB を超えてバッチ処理すると、次のエラーが報告されます。Copy overflow with offset xx, length xx, and array length xx。

ミュータブル配列は 1 行分のスペースしか確保しませんが、追加された配列には複数の行が含まれています。テキスト列が 64 MB を超えると、ビルダーのサイズが 1 行分のみ確保され、必要な最小サイズが考慮されません。

V4.0

• V4.1.6

• V4.0.21

• 回避策: alter database xxx set hg_experimental_enable_batch_accumulator_v2=off; を実行します。

• 最新バージョンにアップグレードします。

P2

ユーザーが SQL ステートメントを実行する際、Alibaba Cloud アカウント名が自動的に 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

バッチコピー処理中に共有メモリが一杯になると、ERROR: Parse data from copy encountered internal error というエラーが発生するか、コアダンプが発生します。スタックトレースには holo_copy または CopyReadLineText が含まれます。

バッチコピーモードでは、クライアントデータは行数でバッチ処理され、共有メモリに書き込まれます。1 行が大きい場合（バッチあたり約 600 MB）、複数の接続からの同時書き込みにより共有メモリが枯渇する可能性があります。これにより、後続の書き込みが失敗するか、読み取り側がオーバーフローにより無効な値を読み取るためプロセスがクラッシュします。

V1.1

• V4.1.5

• V4.0.21

• V3.2.31

• 回避策: ストリーミングコピー書き込みを使用するか、hg_experimental_query_batch_size パラメーターの値を減らします（デフォルト: 8192）。例: alter user xx set hg_experimental_query_batch_size = 512;。

• 最新バージョンにアップグレードします。

P2

Parquet ファイルから配列列を読み取る際、ページインデックススキッピングによりエラーが発生します。この問題は、ページインデックスが有効になっている場合（デフォルト）、SQL クエリが配列列を読み取り、述語プッシュダウンが Parquet リーダーに任意の列のページをフィルタリングする場合にトリガーされます。

ページインデックススキッピングロジックと配列列の読み取りの間に互換性の問題があります。述語プッシュダウンによりページがスキップされると、配列列の読み取り状態が正しく同期されません。

V3.1

• V4.1.5

• V4.0.19

• V3.2.29

• V3.1.43

• 回避策: ページインデックスを無効にします。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 に競合がなくても行が書き込まれません。

WHERE 条件が定数式の場合、条件が正しく書き換えられず、条件を満たすデータが書き込まれません。

V4.0

• V4.1.6

• V4.0.24

• INSERT OR IGNORE 構文を使用し、ON CONFLICT 式で定数条件を使用しないでください。

• 最新バージョンにアップグレードします。

P2

Parquet リーダーは空の行グループを処理できません。行数が 0 の行グループを読み取ろうとするとエラーが報告されます。Hologres V3.1 以降では、これによりコアダンプが発生し、スタックトレースに hologram::spi::parquet::RowRange が含まれます。

リーダーは行グループにデータが含まれていることを前提としています。空の行グループを処理する際、データページパーサーが返すファイルの終わり (EOF) マーカーが無視され、エラー処理ロジックが誤ってトリガーされます。

V3.0

• V4.1.4

• V4.0.19

• V3.2.29

• 回避策: hiveqe を使用してクエリを実行し、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

バルクロード操作中に空のファイルを送信すると、フラッシュ操作が失敗します。サイズが 0 のファイルを送信すると、後続のフラッシュ操作でファイルを開いてメタデータを読み取ることができないため失敗します。

バルクロード操作が削除コンパクションをトリガーすると、選択されたファイルのすべての行が削除対象としてマークされ、空のファイルが生成されます。

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

Fixed plan で、グローバルセカンダリインデックスにブール型が含まれるテーブルへの書き込み操作が失敗します。グローバルインデックスを作成してデータを挿入すると、次のエラーが報告されます。ERROR: XX000: internal error: unexpected error, failed to write, detail: Unsupported type in fixed dispatcher.

Fixed ディスパッチャーは、グローバルセカンダリインデックスへのブール値の書き込みをサポートしていません。

V4.0.0

• V4.0.16

• V4.1.2

• 最新バージョンにアップグレードします。

P2

Holo FDW を使用したクロスインスタンスクエリが失敗します。V4.0 にアップグレードした後、外部テーブルをクエリすると、次のエラーが報告されます。Fetch table group shards failed on meta proxy:Loading cached shard location value for table group[...] failed。

FDW がキャッシュされたシャードの場所値をロードできません。

V4.0.6

• V4.0.15

• V4.1.1

• 最新バージョンにアップグレードします。

P2

マスキングされたテーブルから、自動インクリメント列を持つ宛先テーブルにデータを書き込むと、予期しない動作が発生します。Hologres V4.0 以前では、この操作によりコアダンプまたは異常なエラー動作が発生する可能性があります。

コードは parsetree->targetList と rte_insert->insertedCols の間に 1 対 1 のマッピングがあることを前提としています。この前提は、宛先テーブルに自動インクリメント列が含まれる場合に無効になります。なぜなら、parsetree->targetList には自動インクリメント列とユーザー指定列の両方が含まれるのに対し、rte_insert->insertedCols にはユーザー指定列のみが含まれるためです。

V3.1

• V3.2.26

• V4.0.14

• V3.1.42

• 自動インクリメント列の使用を避けてください。

• 最新バージョンにアップグレードします。

P2

Array Ref インターフェイスはスレッドセーフではなく、コアダンプを引き起こす可能性があります。Hologres V2.2 以降では、ワーカーレベルのシャッフルおよび QE v2 のシャッフルロジックにおいて、マルチスレッドによる array->type へのアクセスによりコアダンプが発生し、配列の type フィールドが無効な値になります。

ArrayRef 型取得インターフェイスは const としてマークされていますが、mutable キーワードにより type_ メンバー変数の変更が許可されています。複数のスレッドによる type への同時アクセスにより、type_ の制御ブロックが破損し、スレッドセーフの問題が発生します。

V3.1

• V4.1.6

• V4.0.21

• V3.2.31

• V3.1.45

• 一時的な回避策: ワーカーレベルのシャッフルおよび QE v2 を無効にします。set hg_experimental_enable_worker_level_connection = off; set hg_experimental_enable_qe_v2 = off;。

• 最新バージョンにアップグレードします。

P2

ALTER DEFINITION ステートメントを使用して既存の動的テーブルに列を追加する際、ベーステーブルが物理パーティションテーブルで、動的テーブル (DT) が論理パーティションテーブルの場合、ALTER DEFINITION ステートメントを DT に対して実行すると、次のいずれかのエラーが報告されます。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。

作成プロセス中に、クエリオプティマイザーのパーティション数チェックを無視する GUC パラメーターが設定されましたが、このロジックは ALTER DEFINITION プロセスで同期されませんでした。

V3.1

• V3.1.40

• V3.2.24

• V4.0.12

• V4.0.13

• 回避策: GUC パラメーターを設定してから ALTER DEFINITION を実行します。set hg_experimental_check_selected_partition_table_number_for_dynamic_table = off;。

• 最新バージョンにアップグレードします。

P2

外部動的テーブルを作成する際、重複する主キーエラーが報告されます。これは、外部 DT の SELECT クエリが同一のテーブルを複数回結合またはユニオンする場合に発生します。その結果、生成されたベーステーブルリストに重複が含まれ、システムテーブルへのデータ挿入時にエラーが発生します。ERROR: duplicate key value violates unique constraint "pg_holo_external_dynamic_table_dependencies_name_index"。

この問題は、動的テーブルと外部動的テーブルの両方に影響します。動的テーブルのシステムテーブルには主キーがありませんが、外部動的テーブルのシステムテーブルには主キー制約があるため、重複レコードの挿入が禁止されます。

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 型の集計結果の type_modifier フィールドが推論されません。そのため、集計結果の 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

ビューにエイリアスのないサブクエリが含まれている場合、スナップショット SQL の実行が失敗します。ビューの SELECT 文で subquery alias optional 特徴を使用してエイリアスのないサブクエリを作成する場合、hg_dump_script によって生成されたスナップショット SQL を実行すると、エラー「unnamed_subquery は存在しません」が返されます。

PostgreSQL がビュー定義 SQL をビュー規則から推測する際、サブクエリのエイリアスを強制しません。ユーザーのビューにエイリアスのないサブクエリがある場合、推測されたビュー定義 SQL もエイリアスを欠き、ターゲットリストがそれを指定しているため、SQL 解析に失敗します。

V4.0

• V4.1.6

• V4.0.12

• CREATE OR REPLACE を使用して、各サブクエリにエイリアスを提供するようにビューを再作成します。

• 最新バージョンにアップグレードします。

P1

Paimon Deletion Vector (DV) テーブルを主キーでグループ化した後、重複レコードが表示されます。これは、Parquet ファイルに FIXED_LEN_BYTE_ARRAY 物理形式、decimal 論理形式、および plain エンコーディングを持つページが含まれ、その列から読み取られたレコードバッチがページ境界をまたぐ場合に発生します。境界をまたいだバッチ内のデータが、レコードバッチの先頭に誤って配置されます。

Parquet デコーダーはデータ配置時にオフセットを適用しないため、レコードバッチがページ境界をまたぐ場合にデータの位置が不正確になります。

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

MaxCompute テーブルクエリが Common Table アクセスパスに切り替わった後、Auto Analyze がテーブルの最新の最終更新時刻を取得できなくなり、メモリ不足 (OOM) エラーが発生する可能性があります。Hologres V3.0.51 にアップグレードした後、Common Table パスを使用して外部テーブルをクエリすると、OOM エラーが継続する可能性があります。MaxCompute テーブルの 3 レベルモデルでは、Common Table アクセスパスからの応答のスキーマ名が Hologres のプロジェクト名ではなく default になります。これにより、Auto Analyze が外部テーブルの最終更新タイムスタンプのバッチ取得に失敗し、変更情報が収集されません。

Common Table アクセスパスと holo_native は、3 レベルモデルの処理において整合していません。fetcher->GetTables インターフェイスの 3 レベルモデルでは、holo_native は project_name を schema_name として返しますが、Common Table アクセスパスは default を schema_name として返します。これにより、データバックフィルが失敗します。

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 から 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 の最初の子から生成された runtime filter が 2 番目の子にプッシュダウンされ、クエリ結果のデータが失われる可能性があります。

UNION ALL 操作の 2 番目の子へのマッピングおよびプッシュダウンプロセス中に、最初の子からの runtime filter が誤ってマージされ、誤ったプッシュダウンが行われます。

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

Hologres V4.0.7 以降にアップグレードした後、名前が変更された、またはスキーマが変更された動的テーブルは自動更新できなくなります。次のエラーメッセージが報告されます。ExecuteQuery failed, last errmsg: Can not find dynamic table properties of XXX または relation "XXX" does not exist。

動的テーブルは、ドライバーで FE (Frontend) から最新のプロパティを定期的にフェッチする必要があります。コードがテーブルドライバーからドライバーマスターに移動された際、最新のテーブル名とスキーマ名を同期するロジックが省略されました。このため、作成時の初期名が使用されることになり、アップグレード後のリフレッシュが失敗します。

V4.0.7

• V4.0.10

• V4.0.13

• 最新バージョンにアップグレードします。

P2

CREATE TABLE AS SELECT (CTAS) ステートメントのパフォーマンスが低下します。これは、クエリ最適化の createstmt フェーズ中の特定の最適化ステップが原因です。

CTAS ステートメントのクエリ最適化フェーズで、不要な最適化ステップがパフォーマンスに悪影響を及ぼします。

V4.0

• V4.0.10

• V4.0.13

• 最新バージョンにアップグレードします。

P1

増分更新された動的テーブルで ANY_VALUE 集計関数を使用すると、不正確な結果が生成されます。ベーステーブルフィールドに 1 つの値しかない場合でも、動的テーブルをクエリすると複数の値が返されます。

FinalizeStateRows で、result_array がループ内で誤って生成されます。このバグは V3.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。

Auto Analyze コレクション中の Common Table アクセスパスの権限変更により、システムがテーブルの最終更新時刻を取得できなくなります。これにより、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

serverless モードで、複数の行レベルトランザクションが開いている間に動的テーブルを更新すると、エラーが発生します。

パッチにより、存在しないテーブルグループのチェックが FE (Frontend) に移動されましたが、serverless シナリオは考慮されませんでした。この問題は、フォロワー virtual warehouse 上で自動ルーティングできない DML ステートメントを実行した場合にトリガーされます。

V4.0

• V4.0.9

• V4.0.13

• リーダー virtual warehouse に権限を付与するか、リーダー virtual warehouse に接続して SQL ステートメントを実行するか、動的テーブルを作成することで、DML 自動ルーティングを使用します。

• 最新バージョンにアップグレードします。

P2

クエリの結果がメモリ不足 (OOM) エラーになります。

シャッフル操作の実行クラス (EC) 優先度が低下したため、CPU 使用率が高い場合に十分なタイムスライスを取得できなくなりました。これにより、ビルド側のデータ取得が遅れ、runtime filter の構築が遅延し、プローブ側が過剰なデータを読み取るようになり、フィルタリング効率が低下します。

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 フィールドが空になります。

ゲートウェイがログイン監査ログを報告する際、クライアント IP アドレスを取得するために追加で getpeername を呼び出します。クライアント接続がすでに異常切断されている場合、IP アドレスを取得できません。

ログイン監査ログをサポートするすべてのバージョン

V4.0.13

• 最新バージョンにアップグレードします。

P2

クラスタリングキーを含むクエリを preparestmt を使用して実行すると、次のエラーが発生します。ERROR: XX000: Dispatch query failed: internal error: DataType::STRING column range conjuncts should use string literal or parameter ref.

mask_md5 はクラスタリングキーです。プリペアドステートメントフェーズでは、式 mask_md5 in (md5($1),md5($2)) を定数畳み込みできません。これにより、抽出されたクラスタリングフィルターに md5 関数が含まれ、バックエンドがこのフィルターを解析できないためエラーが報告されます。

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 句を含むクエリを実行中または手動で早期キャンセルした場合、クエリが失敗し、ワーカーが再起動します。

SplitFactory::Close 関数はリソースを解放しますが、独自の ExecutionContext を使用しません。これにより、他の関数が終了する前にリソースが解放され、コアダンプがトリガーされます。

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 のアンロード後、Holoweb ログインが失敗し、メタデータウェアハウスが次のエラーを報告します。ERROR: 42704: Table group[bizp.bizp_tg_default] is not found in warehouse bdmp_api_warehoue。ゲートウェイメトリクスは新しい接続リクエストの数とレイテンシが高くなっていることを示し、短時間で多数の新しい fixed fe 接続が作成されます。起動時に binlog を消費している際、ロック取得に時間がかかり、高い同時実行性により insert 操作が停止することがあります。

アンロードが発生すると、古い virtual warehouse 上の binlog や Fixed Plan リクエストなどの新しいリクエストが bhclient で 27.5 秒間リトライします。FixedFE 上の EC への接続時に binlog 消費が同期的にこのメソッドを呼び出すため、リトライが発生すると EC への接続がブロックされ、新しい FixedFE 接続の作成が停止し、接続が滞留します。

V3.2

V4.0.8

• binlog 消費タスクを停止し、Flink ジョブを正しい virtual warehouse を使用するように変更します。または、HoloWeb にログインして、アンロードされたテーブルグループをターゲット virtual warehouse にロードします。HoloWeb にアクセスできない場合は、バックエンドから FE (Frontend) 開発者に連絡してゲートウェイを再起動してもらってください。

• 最新バージョンにアップグレードします。

P2

Hologres V3.1 では、動的テーブルの自動更新を有効にした後、7 日間の期間で観察すると、コンテナメモリが継続的に増加します。FE メモリは増加しますが、holo worker メモリは安定しています。hg_generate_query_options_for_dynamic_table を繰り返し実行しても、メモリは継続的に増加します。

UDF hg_generate_query_options_for_dynamic_table にメモリリークがあります。UDF は HoloQmDispatcher オブジェクトをインスタンス化します。このオブジェクトは shared_ptr によって管理されますが、DispatcherManager は query_id をキーとするマップに格納します。コードによって作成された query_id は個別の ID であり、UDF を実行するクエリの query_id ではありません。クエリが完了すると、RemoveDispatcher(query_id) を呼び出してディスパッチャーを削除する必要がありますが、この手順がコードに欠落しています。DispatcherManager のライフサイクルは接続 (conn) プロセスにバインドされているため、ディスパッチャーオブジェクトが時間の経過とともに蓄積されます。

V3.1.0

• V4.0.0

• V3.1.26

• V3.2.8

• 回避策: pg_stat_activity で長時間稼働している接続を見つけて終了するか、1 時間以上経過した接続を自動的にクリーンアップする cron ジョブを登録します。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 つのワーカーが存在し、シャードの偏りはありません。監視では、FE (Frontend) メモリに大きな差異が見られます。メモリが増加し始めた時点からのクエリを調べると、クエリ数が 1000 を超える DDL ステートメントを実行した長時間稼働している接続が明らかになります。

DDL 実行プロセスにメモリリークがあります。QueryDesc オブジェクトのメモリは、クエリレベルの MemoryContext がクエリ終了時に解放されるときに解放されます。しかし、UtilityStmt (広義の DDL) は長時間稼働する MemoryContext にメモリを割り当てるため、クエリレベルの 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

スペース、特殊文字、大文字小文字が混在した名前を持つテーブルを作成すると、インスタンスが一時的に再起動する可能性があります。

システムテーブルからテーブルプロパティを取得する際に、インスタンスが誤った状態を読み取るため、コアダンプが発生します。

• 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

仮想ウェアハウスが lightweight connection モードでソーステーブルの binlog を消費し、ソーステーブルの Table Group がロードされていない場合、インスタンスが新しい接続を作成できなくなる可能性があります。このモードは、Flink ソーステーブルパラメーター connection.fixed.enabled が有効になっている場合、または特定のインスタンスバージョンでデフォルトで有効になります。

lightweight connection モードでの初期化中に、現在の仮想ウェアハウスが Table Group をロードしていないため、リクエストが自動的にリトライされます。これらのリトライ中に、エラーハンドリングパスが誤ってグローバルロックを保持するため、新しい接続リクエストがブロックされます。

• V3.1.13

• V3.2.10

• V4.0.0

• V4.0.8

• 最新バージョンにアップグレードします。

• インスタンスに十分な接続がある場合は、ソーステーブルの connection.fixed.enabled パラメーターを false に設定します。

P1

ストリーム-ストリーム結合を含む増分動的テーブルの最初の更新時、または REFRESH OVERWRITE を実行時に失敗する可能性があります。

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

テーブル定義にストリーム-ストリーム結合結果に基づく集計が含まれる場合、集計結果が不正確になる可能性があります。

最初の増分更新時に、最近削除されたデータが計算に含まれることがあり、エラーまたは不正確な結果を引き起こします。

• V3.2.5

• V4.0.1

• V4.1.1

• V4.0.21

• V4.1.6

• 最新バージョンにアップグレードします。

P2

array_to_string 関数を 2 つの引数で呼び出すと、入力データの NULL 値が計算に含まれます。この動作は PostgreSQL と一致しません。PostgreSQL では、NULL 値は除外されます。

HQE エンジンのロジック不具合により、array_to_string 関数の 2 引数呼び出しが影響を受けます。

• 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 実行エンジンへの入力列の間に不一致があるため、エラーが発生します。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.33

• V3.2.24

• V4.0.13

• PQE 実行エンジンを使用しないように SQL を書き直します。

• 最新バージョンにアップグレードします。

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 列をセグメントキーまたはクラスタリングキーとして使用したフィルタリングが、結果セットのフィルタリングに失敗します。

ストレージエンジンのセグメントキー抽出ロジックに問題があり、フィルタリングが正しく行われません。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.24

• V4.0.13

最新バージョンにアップグレードします。

P1

V4.0 へのアップグレード後、メモリ使用量が継続的に増加し、アクティブなクエリがなくても安定化または減少しません。

V4.0 の結果キャッシュパスで、ディクショナリ配列を処理する際にメモリリークが発生します。

• V4.0.0

• V4.0.10

• この問題を回避するには、機能フラグを無効にしてください。

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

• 最新バージョンにアップグレードします。

P2

CTE を再利用する場合、システムがクエリプランを生成できず、エラーが返されます。

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

• 回避策として、CTE 戦略をインライン化に変更します。

  ALTER DATABASE <database_name> 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

PQE 出力がシャッフルフェーズをバイパスし、同じテーブルグループ内の別の列指向テーブルからのスキャン結果と直接 JOIN または UNION ALL で使用される場合、PQE 結果にデータが欠落する可能性があります。これは、次の条件がすべて満たされる場合に発生します。

• 列指向テーブルが主キーインデックスを使用しており、ポイントシークがトリガーされます。

• データが PQE によって直接処理されます。

列指向テーブルが主キーインデックスを使用している場合、クエリオプティマイザー (QO) によって生成されたプランには Gather オペレーターが含まれません。バケット数がシャード数と等しくなく、1 つのバケットに複数のシャードが含まれる場合、PQE が 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 すると失敗します。進捗ビューに一時テーブルに列が見つからないというエラーが報告されます。

古いバージョンの Rebuild プロセスは、大文字小文字を区別する識別子を正しく処理できませんでした。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.40

• V3.2.25

• V4.0.13

最新バージョンにアップグレードします。

P2

CASE WHEN 式を含むサブクエリにより、次のエラーが発生します。

ERROR: column "xxx" does not exist

このシナリオに対して、クエリオプティマイザーが有効なプランを生成できません。

• 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 を消費する際、ソーステーブルが物理テーブルの列のサブセットを定義している場合、予期しない NULL 値が取り込まれる可能性があります。

Hologres の Flink コネクタは、投影された列を使用した 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

完了したクエリが正しくクリーンアップされず、テーブルロックを保持する残留トランザクションが残る可能性があります。

完了したクエリのガベージコレクション (GC) ロジックに不具合があり、残留クエリ識別子 (query_id) が発生します。

• V2.2.0 以前

• V3.0.0

• V2.2.32

• V3.0.12

• 最新バージョンにアップグレードします。

• 残留クエリを手動でクリーンアップするには、次の SQL コマンドを実行します。

  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 バージョン: Postpone テーブルの SnapshotReader は自動的に onlyReadRealBuckets オプションを追加しました。このオプションにより、最終的な圧縮済みデータのみが読み取られました。

• 新しい Paimon SDK バージョン: この自動ロジックが削除されました。最終データのみを読み取るには、SnapshotReader に手動でこのオプションを設定する必要があります。

• V3.2.12

• V4.0.0

• V3.2.24

• V4.0.11

• 最新バージョンにアップグレードします。

P1

bucket_num=-2 を使用して DLF 外部テーブルをクエリする際、マルチテーブル結合で不正確な結合プランが生成され、クエリ結果が不正確になる可能性があります。

Paimon テーブルの bucket_num がマルチテーブル JOIN シナリオで -2 に設定されている場合、不正確な JOIN プランが生成され、データが効果的に結合されず、クエリ結果が不正確になります。

• 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

必要な権限を持っていても、hologres.hg_query_log および hologres.hg_table_info のクエリ結果が空になります。

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

マルチストリーム結合を持つ動的テーブルの増分更新中に、1 つのストリームのみにデータが含まれ、そのデータに取り消しが含まれる場合、直接クエリした場合と比較して更新結果が不正確になります。

動的テーブルの増分更新中に、単一ストリームからのデータ取り消しが正しく処理されません。その結果、結果テーブルから削除されるべき行が削除されず、結果テーブルが不正確になります。

• V4.0.1

• V4.0.9

• まずテーブルデータを変更し、次に refresh overwrite を使用して誤ったデータを修正します。次の 2 つの 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 へのアップグレード後、ワーカーの OOM エラーが発生する可能性があります。エラーメッセージは次のとおりです。

1. エラー: ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

2. エラー: ERROR: Dispatch query failed: Connect to xxx.xxx.xxx:xxx failed

V4.0 では、より多くのデータをメモリにキャッシュするためにメモリ構造が最適化されています。ただし、この新しい構造には Decimal 型を処理する際の不具合があります。Decimal 列を含むテーブルがハッシュ結合に参加すると、インスタンスがコアダンプを生成する可能性があります。

• V4.0.0

V4.0.10

• 一時的な回避策として、次の SQL コマンドでクエリメモリ最適化を無効にします。

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

• 最新バージョンにアップグレードします。

P1

MaxCompute Append Delta テーブルが空でないにもかかわらず、クエリ結果が空の結果セットを返します。

スプリットキャッシュのバグにより、クエリが空の結果を返します。

• V4.0.0

V4.0.9

• 一時的な回避策として、次のコマンドでスプリットキャッシュを無効にします。

ALTER DATABASE <database_name> set hg_experimental_enable_maxcompute_sdk_splits_cache=off;

• 最新バージョンにアップグレードします。

P0

V4.0 では、主キーとクラスタリングキーを持つ論理パーティションテーブルを使用する際、重複する主キー値が発生する可能性があります。

論理パーティションテーブルの書き込みパフォーマンスを向上させるために、V4.0 ではマルチパーティションフラッシュがサポートされています。ただし、この操作中のクラスタインデックス処理ロジックにバグがあり、Pangu に保存されている AliORC ファイル（内部列指向テーブルのデータファイル）のクラスタインデックスが破損する可能性があります。破損したクラスタインデックスにより、既存のデータが読み取れなくなります。その結果、更新時に古いデータが見つからず、新しい行が挿入され、重複が発生します。

• V4.0.0

V4.0.9

• 最新バージョンにアップグレードします。アップグレード後、システムは破損したファイルを検出するロジックを追加します。破損したファイルがスキャンされると、次のエラーが報告されます。clustered_index size [x] incorrect. このエラーが発生した場合は、影響を受けたテーブルに対して完全コンパクションを実行して修復してください。詳細については、「パーティションテーブル FAQ」をご参照ください。

P1

V4.0 へのアップグレード後、ワーカーの OOM エラーが発生する可能性があります。エラーメッセージは次のとおりです。Error 1: ERROR: XX000: ERPC_ERROR_CONNECTION_CLOSED

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

V4.0 では、より多くのデータをメモリにキャッシュするためにメモリ構造が最適化されています。ただし、この新しい構造ではデータサイズの計算を誤り、必要なメモリ量を過小評価するため、ワーカーの OOM が発生します。

• V4.0.0

V4.0.7

• 一時的な回避策として、次のコマンドで結果キャッシュを無効にします。

ALTER DATABASE <database_name> set hg_experimental_enable_result_cache=off;

• 最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョン

修正済みバージョン

回避策

P1

Flink リアルタイム書き込みシナリオで、ユーザーを削除して同じ名前と権限を持つユーザーを再作成しても、新しいユーザーに権限エラーが発生する可能性があります。これは、新しい接続を使用していても発生します。

FixedFE コンポーネントのユーザーパーミッションキャッシュ更新戦略に問題があります。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.38

• V3.2.21

• V4.0.9

• 最新バージョンにアップグレードします。

P1

動的テーブルのストリームモードでの増分更新中に、ソーステーブルに対して INSERT、UPDATE、または DELETE 操作を実行した直後に TRUNCATE または INSERT OVERWRITE を実行すると、後続の更新に不正確なデータが含まれる可能性があります。

ソーステーブルの DML 操作 (INSERT、UPDATE、または DELETE) の直後に TRUNCATE または INSERT OVERWRITE を実行すると、動的テーブルが同じ主キーに対する重複する DELETE メッセージを処理し、データが不正確になります。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 最新バージョンにアップグレードします。

P2

汎用インスタンスのリバランス操作を実行するために SELECT hg_rebalance_instance() を実行すると、shard group not found エラーが発生します。

汎用インスタンスのリバランス時に、誤ったデフォルトパラメーターが渡されます。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 最新バージョンにアップグレードします。

P2

スケーリング操作中に、テーブルグループのプライマリおよびセカンダリ仮想ウェアハウスでまれに ShardPermissionDenied エラーが発生し、一時的な書き込みエラーが発生する可能性があります。

スケーリング中に ShardPermissionDenied エラーを再試行可能な kShardHotMigrationInProgress エラーに変換するようにシステムが設計されています。ただし、この変換が失敗し、元のエラーがクライアントに返されます。

• V3.1.0

• V3.2.0

• V4.0.0

• V3.1.37

• V3.2.20

• V4.0.8

• 最新バージョンにアップグレードします。

P2

MaxCompute の Common Table アクセスパスに切り替えた後、MaxCompute 外部テーブルを使用する動的テーブルの更新が次のエラーで失敗します。

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

動的テーブルのクエリプランの渡し方は通常の OLAP クエリとは異なります。送信中にプランのバイナリデータが破損し、フィルターの解析に失敗します。

• 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

標準 PostgreSQL 権限モデルを使用する際、動的テーブルに所有者権限を付与していても、所有者として履歴テーブルまたはパーティションを更新すると、Permission Denied エラーが発生する可能性があります。

更新に使用される ID がキャッシュされます。権限が変更された後、キャッシュされた古い ID が後続の更新で誤って使用され、エラーがトリガーされます。

• V3.1.0

• V3.2.0

• V4.0.0

• 修正予定

• 最新バージョンにアップグレードします。

P2

DLF で timestamp 列に対する範囲フィルターを使用してデータをクエリすると、次のエラーが発生します。

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

システムがリテラル型を誤って処理し、long リテラルとして扱います。

• V3.2.0

• V4.0.0

• V3.2.17

• V4.0.6

• 一時的な回避策として、Bigmeta アクセスパスを無効にします。

ALTER DATABASE <database_name> set hg_experimental_enable_big_meta=off;

• 最新バージョンにアップグレードします。

P2

主キーにブール型列を含むテーブルに 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

クエリエンジンはブール配列を uint8 配列に変換します。ハイブリッド DML が行グループフィルターを作成する際、このシナリオを考慮していません。その結果、行グループフィルター内のリテラル型 (bool) と実際の値型 (long) の間に不一致が生じます。

• V3.1.0

• V3.2.0

• V3.1.25

• V3.2.7

• 一時的な回避策として、ハイブリッド DML を無効にします。

ALTER DATABASE <database_name> set hg_experimental_enable_hybrid_dml = off;

• 最新バージョンにアップグレードします。

P2

リモート 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

動的テーブルの増分更新のストリームモードを使用する際、ソーステーブルのコンパクション直後に更新を実行すると、増分データの順序が乱れる可能性があります。

同じキーに対する順序が乱れた増分イベントにより、シンクテーブルの結果が不正確になる可能性があります。

• V3.1.0

• V3.2.0

• V3.1.23

• V3.2.6

• 最新バージョンにアップグレードします。

P1

REBUILD コマンドを使用する際:

• binlog 無効時: binlog が無効になっている場合、物理パーティションテーブルを論理パーティションテーブルに再構築すると、結果テーブルで binlog が誤って有効になります。

• binlog 有効時: binlog が有効になっている場合、物理パーティションテーブルを論理パーティションテーブルに再構築すると、結果テーブルで 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

高階配列関数を使用する際、結果配列のすべての要素が同一の場合、結果が誤って単一要素配列に重複排除される可能性があります。例:

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 のテーブル再シャーディング機能を使用する際、タスクが失敗してキャンセルされた後、一時テーブルが正しくクリーンアップされません。この一時テーブルに対して手動で DROP TABLE を実行すると、フロントエンド (FE) が応答しなくなります。

HoloWeb のクリーンアップ関数に不具合があります。

影響を受けたバージョン:

• V2.0.24

修正済みバージョン:

• V2.2.28

最新バージョンにアップグレードします。

P2

HG_MOVE_TABLE_TO_TABLE_GROUP (再シャーディング) 関数が、特殊文字を含むテーブル名またはキーワードであるテーブル名に対して失敗します。この関数は静かに失敗し、テーブルグループは変更されません。

HG_MOVE_TABLE_TO_TABLE_GROUP 関数が文字のエスケープ処理を誤っています。

影響を受けたバージョン: すべてのバージョン

修正済みバージョン: なし。回避策を参照してください。

V3.1 以降にアップグレードし、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 path にフォールバックすると、一部のデータセグメントがスキップされ、部分的なデータ損失が発生します。

外部テーブルの読み取りが SQE path にフォールバックすると、適応型インポート機能によりデータセグメントがドロップされ、データ損失が発生します。

影響を受けたバージョン:

• 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 以降。

インスタンスレベルで adaptive import 機能を無効にします。次の GUC を設定します。

ALTER ROLE ALL SET hg_experimental_enable_adaptive_adjust_bulkload_dop = off;

P1

データマスキングを設定した後、テーブルの UPDATE 操作によりクエリ結果にマスクされていないデータが返される可能性があります。例:

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

インスタンスを再起動した後、動的テーブルが自動的に更新されなくなります。

バックエンドのスケジューリングシステムに問題があります。

影響を受けたバージョン:

• V3.0.0-V3.0.45

• V3.1.0-V3.1.24

• V3.2.0-V3.2.6

修正済みバージョン:

• V3.0.46

• V3.1.25

• V3.2.7

• V4.0.0

最新バージョンにアップグレードします。

P1

論理パーティションと自動更新が有効な動的テーブルで、アクティブパーティションが非アクティブになると、増分更新から完全更新への切り替えに失敗し、ストレージが継続的に増加する可能性があります。

動的テーブルのアクティブパーティションの状態遷移をシステムが誤って処理します。

影響を受けたバージョン:

• V3.1.0-V3.1.23

• V3.2.0-V3.2.6

修正済みバージョン:

• V3.1.24

• V3.2.7

最新バージョンにアップグレードします。

P2

クラスタリングキーが NULL 許容の動的テーブルを設定する際、ALTER DYNAMIC TABLE ステートメントを実行すると、clustering_key should not be nullable というエラーが発生します。

ALTER DYNAMIC TABLE ステートメントがクラスタリングキーのプロパティを正しく推測できません。

影響を受けたバージョン:

• V3.1.0-V3.1.31

• V3.2.0-V3.2.11

修正済みバージョン:

• V3.1.32

• V3.2.12

最新バージョンにアップグレードします。

P2

クラスタリングキーを持たない列指向テーブルで、主キーに重複が発生する可能性があります。これは、INSERT ON CONFLICT DO UPDATE を使用したオフラインインポート後にリアルタイム書き込みを実行した場合に発生します。

オフラインインポート中に主キーのデータが正しく処理されないため、後続のリアルタイム書き込みで既存のキーを検出できず、主キーの重複が発生する可能性があります。

影響を受けたバージョン:

• 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 GUC が有効であっても、依然として duplicate key value violates unique constraint エラーが報告される可能性があります。

重複データに遭遇した際、hg_experimental_affect_row_multiple_times_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 を使用して外部データベースの外部テーブルから読み取る際、SQL クエリがハングする可能性があります。

hg_insert_overwrite コマンドが外部データベースへのアクセスでタイムアウトし、クエリがハングします。

影響を受けたバージョン:

• V3.1.0-V3.1.21

• V3.2.0-V3.2.4

修正済みバージョン:

• V3.1.22

• V3.2.5

最新バージョンにアップグレードします。

レベル

説明

原因

バージョン

回避策

P1

worker node が、クエリリクエストの完了後にハングする可能性があります。これにより、関連テーブルに対する DDL 操作や LIMIT 句を含むクエリがブロックされます。次のいずれかの理由でクエリリクエストが完了した場合に発生します。

• メモリ不足 (OOM) エラーが発生しました。

• 手動でキャンセルされました。

• 例外により手動でキャンセルまたは終了された場合。

クエリ完了後のクエリエンジンのリソースクリーンアッププロセスに不具合があります。

影響を受けたバージョン:

• 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 を使用して、Alibaba Cloud AccessKey (Alibaba Cloud アカウント、RAM user、または RAM role のもの) を持つ Hologres instance に接続する際、1 日の特定の時間帯に接続が失敗します。この時間帯は client time zone に依存します。たとえば、UTC+8 では 00:00:00+08 から 08:00:00+08 まで、UTC-5 では 19:00:00-05 から 00:00:00-05 までです。

Holo Client V2.6.0 のタイムゾーン処理に問題があります。

この問題は Holo Client V2.6.0 固有であり、Hologres instance バージョンとは無関係です。

Holo Client を V2.6.1 以降にアップグレードします。

P0

Hologres V3.1 では、ストリームモードでベーステーブルデータを消費する読み取り専用の動的テーブルを持つインスタンスが、連続再起動ループに入る可能性があります。

動的テーブルが読み取り専用状態にある場合、データフラッシュが失敗し、連続インスタンス再起動がトリガーされます。

影響を受けたバージョン:

• 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

Data Lake Formation (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

動的テーブルを作成し、ソースクエリに BOOLEAN データ型が含まれている場合、更新操作が次のエラーで失敗します。ERROR: Internal error: HGERR_code XX000 HGERR_msge can not get pg type string %s: id: UINT8。

動的テーブル機能が BOOLEAN フィールドのデータ型を誤って推測するため、更新操作が失敗します。

影響: 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 では、増分更新が有効な動的テーブルを削除しても、その状態テーブルは削除されません。

増分更新を使用する動的テーブルを削除する際、関連付けられた状態テーブルのクリーンアップが失敗します。

影響: V3.1.1 ～ V3.1.12。

修正: V3.1.13 以降。

最新バージョンにアップグレードします。

P2

異なるスキーマ間で 64 ビット RoaringBitmap 関数 (例: rb_or_cardinality_agg) を使用すると、次のエラーが発生します。Unsupported agg function:public.rb_or_cardinality_agg。

64 ビット RoaringBitmap 関数のスキーマ推論が誤っており、クロススキーマクエリが失敗します。

影響:

• V3.1.1 ～ V3.1.11

• V3.2.0

修正:

• V3.1.12 以降

• V3.2.1 以降

最新バージョンにアップグレードします。

P2

ベーステーブルが NOT NULL 列を持つ論理パーティションテーブルとして動的テーブルを作成すると失敗し、次のエラーが返されます。failed:the index xx "xxx" should not by nullable。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

失敗の原因は、動的テーブルの NOT NULL 属性の推論が誤っているためです。

影響:

• V3.1.1 ～ V3.1.11

• V3.2.0

修正:

• V3.1.12 以降

• V3.2.1 以降

最新バージョンにアップグレードします。

P2

単一テーブル上のマテリアライズドビューに SUM(DECIMAL) 集計を含めると、インスタンスが一時的に再起動する可能性があります。

SUM(DECIMAL) をマテリアライズドビューで計算する際、メモリのアライメントミスによりインスタンスがコアダンプを生成する可能性があります。

影響:

• 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

修正:

• バージョン 3.1.17 以降。

• V3.0.44 以降

• V3.2.2 以降

最新バージョンにアップグレードします。

P0

特定の同時実行シナリオで、Serverless Computing を使用してテーブルに対して DML 操作を実行しながら、同じテーブルに対して TRUNCATE TABLE または DROP TABLE を実行すると、テーブルのシャードで読み取り/書き込み例外が発生する可能性があります。これは、内部エンジンの状態同期の問題が原因です。

エンジンの同時実行の問題により、シャード内で異常な内部状態が発生し、一時的に読み取り/書き込みリクエストを処理できなくなります。この問題は他のテーブルへのアクセスにも影響を与える可能性があります。

影響:

• V2.1.45 以前

• V2.2.45 以前

修正:

• V2.1.46

• V2.2.46

• V3.0.27 以降

• V3.1.1 以降

• 一時的な回避策:

  • DML と TRUNCATE TABLE/DROP TABLE 操作を異なるタイミングで実行します。

  • DML 操作に Serverless Computing を使用しないでください。

• 推奨ソリューション:

  最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P1

仮想ウェアハウスインスタンスのスケールアウト中に、compute node が時折再起動する可能性があります。

テーブルに対する DML タスクとコンパクションタスクの同時実行が、スケールアウト中にこの問題をトリガーする可能性があります。

影響を受けたバージョン: V3.0.1。

修正済みバージョン: V3.0.28 以降。

最新バージョンにアップグレードします。

P1

GIN インデックスを使用した JSONB 列指向ストレージ最適化を有効にしているインスタンスが、予期せず再起動する可能性があります。

JSONB 列指向ストレージ最適化と GIN index の間に互換性の問題があります。

影響を受けたバージョン: V3.1.1。

修正済みバージョン:

• V3.0.42 以降。

• V3.1.10 以降。

• テーブルから GIN index を削除します。

• 最新バージョンにアップグレードします。

P2

完全にビューに基づく動的テーブルをリフレッシュすると、インスタンスが再起動する場合があります。

ビューを base tables として使用する動的テーブルを更新する際、処理エラーによりコアダンプが発生します。

影響を受けたバージョン: V3.1.8。

修正済みバージョン: V3.1.9 以降。

最新バージョンにアップグレードします。

P2

動的テーブルの incremental refresh mode で、ARRAY_AGG 関数を使用するクエリが、すべてのデータがフィルターによって削除された場合、null ではなく空の結果を返します。

なし。

影響を受けたバージョン:

• V3.0.40。

• V3.1.7。

修正済みバージョン:

• V3.0.41 以降。

• V3.1.8 以降。

最新バージョンにアップグレードします。

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 関数が指定された time zone を誤って破棄し、デフォルトで UTC を使用します。

影響を受けたバージョン: V3.0.40。

修正済みバージョン: V3.0.41 以降。

最新バージョンにアップグレードします。

P2

virtual warehouse instance で、PG_RELATION_SIZE、PG_DATABASE_SIZE、および HOLOGRES.HG_RELATION_SIZE 関数が不正確なストレージサイズを返します。

仮想ウェアハウスインスタンスで PG_RELATION_SIZE を使用してストレージサイズをクエリすると、値が過大評価され、結果が不正確になります。

影響を受けたバージョン: V3.0.39。

修正済みバージョン: V3.0.40 以降。

最新バージョンにアップグレードします。

P2

incremental refresh mode で、ベーステーブルに複数の重複行が含まれている場合、動的テーブルの更新が ERROR: internal error: Filter has 1 rows but length of columns エラーで失敗します。

増分更新プロセスが、1 回の更新操作中に複数の重複行を正しく処理できません。

影響を受けたバージョン: V3.0.39。

修正済みバージョン: V3.0.40 以降。

最新バージョンにアップグレードします。

P2

マルチテーブル結合を含み、いずれかのテーブルに ARRAY フィールドが含まれる動的テーブルの増分更新操作が、XX000: internal error: Not Implements エラーで失敗します。

マルチテーブル結合の増分更新プロセスが、ARRAY フィールドを含むテーブルを正しく処理できません。

影響を受けたバージョン:

• V3.0.38。

• V3.1.2。

修正済みバージョン:

• V3.0.39 以降。

• V3.1.3 以降。

最新バージョンにアップグレードします。

P1

論理パーティションを持つテーブルへのトランザクションのコミット中に、パーティションキーのカーディナリティが高すぎてパーティション数が 5,200 を超える場合、インスタンスが再起動する可能性があります。

transaction の commit 中に、process がテーブル内の logical partitions の数が上限を超えたことを検出したため、instance が core dump を作成しました。

影響を受けたバージョン: 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 を使用してテーブルコメントをコピーする際に失敗する問題を修正しました。

hg_create_table_like 関数がテーブルコメントを列コメントとして誤ってコピーしていました。

影響を受けたバージョン: 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 クエリが次のエラーで失敗する問題を修正しました。Cannot open a fragment with explicit_seek set to false。

オプティマイザーが結合順序を誤って推論していました。

影響を受けたバージョン: 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

query_id フィールドが hg_stat_activity ビューで不正確になる問題を修正しました。これは、engine_type が {PG} に設定されている場合に発生します。

hg_stat_activity が {PG} に 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

動的テーブルで手動で指定された分散キーが有効にならない問題を修正しました。

エンジンの推論エラーにより、手動で指定された分散キーが無視されました。

影響: V3.0.24 以前。

修正: V3.0.25 以降。

最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P1

Hologres インスタンスに BI ツールや開発者ツールで接続すると、権限のないユーザーでもデータベース、スキーマ、テーブルのメタデータが表示されてしまいます。

メタデータのアクセス制御が十分に厳格ではありません。

影響: V3.0.23 以前。

修正: V3.0.24 以降。

最新バージョンにアップグレードします。

P2

MaxCompute 外部テーブルと hologres_fdw 外部テーブルを結合すると、クエリが error: Build desc failed: Fetch table group shards failed on meta proxy エラーで失敗します。

hologres_fdw 外部テーブルと MaxCompute 外部テーブルの結合中に、内部テーブルのシャードプルーニングで論理エラーが発生します。

影響: 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 Convert Failed や Java heap space などの例外をスローしたり、一部のシャードからのデータ消費が予期せず停止したりすることがあります。

バイナリログ消費中にダウンストリームの Flink オペレーターでバックプレッシャーが発生すると、ソーステーブルのデータが迅速に消費されません。これにより、バックエンドがタイムアウト例外をスローします。ゲートウェイはこの例外を誤ってクライアントに転送し、データ消費ジョブがハングしたり、解析エラーで失敗したりします。

• 影響: V2.2.21 以前。

• 修正: V2.2.22 以降。

最新バージョンにアップグレードし、Flink ジョブを再起動します。

P2

JSONB 列に対して列指向ストレージ最適化が有効で、かつビットマップインデックスも存在する場合、データ書き込み後にフラッシュとコンパクションが失敗する可能性があります。これにより、インスタンスのストレージ消費量とメモリ使用量が増加します。

JSONB 列指向ストレージ最適化の不具合により、BINARY 型のビットマップインデックスを正しく処理できません。

影響:

• 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 (ORDER 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

列名に大文字が含まれている場合、外部テーブルのクエリが失敗します。

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

大文字小文字の変換エラーにより、大文字の列名を持つ外部テーブルのクエリが失敗します。

• 影響を受けたバージョン: V3.0.18 以前。

• 修正: V3.0.19 以降。

最新バージョンにアップグレードします。

P2

OSS エンドポイントが設定されていない場合、DLF のテーブルをクエリすると失敗します。次のエラーが報告されます。

SELECT * FROM openlake_demo_dlf.github_events.ods_github_events_raw;

--エラーメッセージ
ERROR: internal error: external dataset reader missing required oss_endpoint option.

OSS エンドポイントが設定されていない場合、システムは対応する OSS テーブルにルーティングできず、クエリが失敗します。

• 影響を受けたバージョン: V3.0.17 以前。

• 修正: V3.0.18 以降。

最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けた/修正済みバージョン

回避策

P2

DECIMAL フィールドを含む動的テーブルの完全または増分更新が、column type doesn't match, decimal(28, 10) v.s. decimal(38, 10) エラーで失敗します。

システムが DECIMAL フィールドの精度を誤って推測するため、更新が失敗します。

影響: V3.0.16 以前。

修正: V3.0.17 以降。

• クエリで DECIMAL フィールドの精度を手動で指定します。

• 最新バージョンにアップグレードします。

P2

UNION ALL オペレーターの両側のクエリスキーマが一致しない場合、クエリは schema's field number from producers are not equal [1 vs 0] エラーで失敗します。

UNION ALL オペレーターのスキーマ推論が誤っているため、このエラーが発生します。

影響: V3.0.16 以前。

修正: V3.0.17 以降。

最新バージョンにアップグレードします。

P2

増分更新中に動的テーブルの SMALLINT フィールドを集計すると、「unsupported」エラーが発生します。

動的テーブルの増分更新プロセスは、SMALLINT 型を完全にはサポートしていません。

影響: V3.0 ～ V3.0.16。

修正: V3.0.17 以降。

最新バージョンにアップグレードします。

P2

仮想ウェアハウスインスタンスをアップグレードした後、クエリが CreateFile ignore since it's not leader エラーで失敗します。

仮想ウェアハウスのアップグレード中に、システムがテーブルメタデータを迅速に更新できません。これにより、後続のクエリが古いテーブルメタデータを使用し、エラーが発生します。

影響:

• 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 テーブルメタデータへのアクセスに対する権限チェックが厳格化されました。これらの新しいチェックにより、フロントエンド (FE) ノードが複数回の冗長な呼び出しを行い、MaxCompute 外部テーブルのクエリパフォーマンスが低下します。

影響: V3.0 ～ V3.0.13。

修正: V3.0.14 以降。

最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P2

動的テーブルの完全更新モードで Binlog を有効にすると、更新操作で ERROR: internal error: refresh table failed: internal error: new_values is missing col エラーが報告されます。

dynamic table の full refresh mode で binary log を有効にすると、hidden column の導出が一致しないため、更新操作が失敗します。

影響を受けたバージョン: V3.0.11 以前。

修正済みバージョン: V3.0.12 以降。

最新バージョンにアップグレードします。

P2

SLPM 権限モデルで、Orafce 拡張機能を削除してから再作成すると、"role slpm xxx already exists" エラーが発生します。

SLPM permission model では、Orafce extension を削除しても user group の権限が完全に削除されません。その結果、user group が残り、拡張機能の再作成が妨げられます。

影響を受けたバージョン: V3.0.9 以前。

修正済みバージョン: V3.0.10 以降。

• SLPM permission model から standard PostgreSQL authorization model に切り替えてから、Orafce extension を再作成します。

• 最新バージョンにアップグレードします。

P2

Decimal フィールドを含む動的テーブルを更新すると、invalid definition of a numeric type エラーが発生します。

Decimal field の精度推論が誤っているため、dynamic table の更新中に精度が一致しません。

影響を受けたバージョン: V3.0.9 以前。

修正済みバージョン: V3.0.10 以降。

• dynamic table を作成する際に、Decimal field の精度を手動で指定します。

• 最新バージョンにアップグレードします。

P2

10 秒以上実行されるクエリの場合、metadata warehouse の Plan column に EXPLAIN ANALYZE の結果が時々表示されません。

10 秒以上実行されるクエリの報告が時々遅れるため、Plan column が結果を収集できません。

影響を受けたバージョン:

• V3.0.8 以前。

• V2.2.33 以前。

修正済みバージョン:

• V3.0.9 以降。

• V2.2.34 以降。

最新バージョンにアップグレードします。

P2

BIS 型のテーブルを分析すると、Not supported type: bsi0.] in cache failed エラーが報告されます。

BSI 型フィールドの分析サポートが不完全なため、この問題が発生します。

影響を受けたバージョン:

• V3.0.9 以前。

• V2.2.31 以前。

修正済みバージョン:

• V3.0.10 以降。

• V2.2.32 以降。

最新バージョンにアップグレードします。

P2

hg_insert_overwrite を使用した後、生成された一時テーブルが自動的にクリーンアップされません。

hg_insert_overwrite プロセス中にクリーンアップメカニズムがトリガーされなかったため、一時テーブルがクリーンアップされませんでした。

影響を受けたバージョン: V2.2.30 以前。

修正済みバージョン: V2.2.31 以降。

最新バージョンにアップグレードします。

P2

FE node のバージョンが一致しない場合、TRUNCATE 操作を実行すると、操作をキャンセルできなくなり、データの不整合が発生する可能性があります。

FE node のバージョンが一致しないと、ノードリレーが停止し、後続の DDL 操作が失敗する可能性があります。その結果、この期間中に実行された DROP または TRUNCATE 操作はキャンセルできません。

影響を受けたバージョン: V2.2.26 以前。

修正済みバージョン: V2.2.27 以降。

最新バージョンにアップグレードします。

P2

長すぎる SQL ステートメントを実行すると、次のエラーが発生します。ERROR: Current query length xxx exceeds the limit 10000000。

Hologres は、SQL ステートメントの長さをデフォルトで 10,000,000 文字に制限しています。

導入されたバージョン:

• V2.2.22 以降。

• V3.0.1 以降。

SQL の長さ制限を解除するには、次のパラメーターを設定します。

ALTER DATABASE db_name SET hg_experimental_query_length_limit = 0;

レベル

説明

原因

影響を受けた/修正済みバージョン

回避策

P1

データベースの最初の DML トランザクションの後に実行された場合、テーブルに対する同時 DDL 操作によりクエリがハングする可能性があります。

データベースの最初の DML トランザクションがテーブルロックを取得しました。その後、同じテーブルに対する同時 DDL 操作により、システムが作成ループに入り、デッドロックが発生してクエリがハングしました。

影響を受けたバージョン: V2.2.24 以前。

修正済みバージョン: V2.2.25 以降。

最新バージョンにアップグレードします。

P2

roaringbitmap 型のフィールドを含む Hologres テーブルに対して、CREATE FOREIGN TABLE コマンドを使用して roaringbitmap フィールドを含めずにクロスデータベースクエリ用の外部テーブルを作成すると、外部テーブルは正常に作成されます。しかし、SELECT * FROM を使用してこのテーブルをクエリすると、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 コマンドをループで繰り返し実行すると、キャッシュが破損し、失敗しました。

影響を受けたバージョン:

• V2.2.23 以前。

• V3.0.3 以前。

修正済みバージョン:

• V2.2.24 以降。

• V3.0.4 以降。

• CREATE EXTENSION コマンドをデータベースごとに 1 回だけ実行します。

• 最新バージョンにアップグレードします。

P2

メタデータウェアハウスのクエリログの result_rows と affected_rows の値が実際の値と一致しません。

メタデータウェアハウスが result_rows と affected_rows の値を誤って報告したため、不一致が発生しました。

影響を受けたバージョン: V2.2.22 以前。

修正済みバージョン: V2.2.23 以降。

最新バージョンにアップグレードします。

P2

プライマリ仮想ウェアハウスを再起動すると、セカンダリ仮想ウェアハウスのポイントクエリが遅くなる可能性があります。

プライマリ仮想ウェアハウスが再起動すると、セカンダリ仮想ウェアハウスのシャードがプライマリシャードの状態を継続的にポーリングします。このポーリングにより、すべてのシャードが回復するまでポイントクエリがハングします。

影響を受けたバージョン: 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.22 以前、V2.1.42 以前、V2.0.45 以前、V1.3.70 以前。

修正済みバージョン: V3.0.4、V2.2.23、V2.1.43、V2.0.46、V1.3.71 以降のバージョン。

• 短期的な解決策: インスタンスを再起動して一時的に問題を解決します。

• 長期的な解決策: メジャーバージョンの最新パッチバージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P2

仮想ウェアハウスが利用できなくなった場合 (再起動中など)、そのウェアハウスによってロードされたテーブルグループ内のテーブルに対する他の仮想ウェアハウスからのポイントクエリのレイテンシが増加します。

リアルタイム読み書きパスの内部モジュールのバグにより、仮想ウェアハウスがポイントクエリ中にテーブルグループのステータスを待機し、レイテンシが増加します。

影響: 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

Flink ジョブが jdbc または jdbc_fixed モードで Hologres バイナリログを読み取る際、バックプレッシャーによりバックエンドがタイムアウトすると、ジョブがハングしたりフェールオーバーしたりする可能性があります。

ゲートウェイがバックエンドのタイムアウト例外をクライアントに返す方法に問題があり、データ読み取りがハングしたり、解析エラーで失敗したりします。

影響: V1.3 以降。

修正: V2.2.21 以降。

Flink ジョブを最新のチェックポイントから再起動し、最新バージョンにアップグレードします。

P2

V2.2 以降、Parallel Query Engine (PQE) は、シャードプルーニングを使用する COUNT DISTINCT 操作 (実行プランにシャードプルーニング演算子が含まれる場合) を実行すると、パフォーマンスが低下します。

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

シャードプルーニングが適用されると、システムは COUNT DISTINCT の実行プランを誤って推論します。これにより、PQE がクエリを実行し、パフォーマンスが低下します。

影響: V2.2.1 ～ V2.2.18。

修正: V2.2.19 以降。

• 最新バージョンにアップグレードします。

• COUNT DISTINCT を UNIQ に置き換えます。

P2

スロークエリログ (query_log テーブル) で、query_start フィールドの日付形式は 2024-07-08 22:00:00 ですが、query_date フィールドの形式は 19700101 です。

システムがスロークエリログの query_date フィールドを誤って収集します。

影響: V2.2.1 ～ V2.2.18。

修正: V2.2.19 以降。

最新バージョンにアップグレードします。

P2

パーティション分割された子テーブルに書き込む際、COPY 列リストにパーティションキー列が含まれている場合、値 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 の場合、システムはパーティションキーを検証しません。これにより、ダーティデータが書き込まれる可能性があります。

影響: V2.2.1 ～ V2.2.18。

修正: V2.2.19 以降。

最新バージョンにアップグレードします。

P2

接続文字列でタイムゾーンを明示的に SET timezone='+8' に設定し、クエリに to_char などの PQE 日付関数が含まれている場合、クエリは期待される UTC+8 ではなく、誤って UTC-8 タイムゾーンの結果を返します。例:

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 関数が計算中に NULL 許容プロパティを誤って推論するため、クエリが失敗します。

影響: 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 操作を実行すると、テーブルデータの TTL が期限切れになっていなくても、ターゲットテーブルに重複データが時々発生する可能性があります。

UPDATE またはUPSERT 操作中に、ターゲットテーブルとソーステーブルが結合されます。2 つのテーブルの結合キーが異なる場合、ターゲットテーブルが再配布される可能性があります。このシナリオで、ソーステーブルに重複データがある場合、オプティマイザーがそれを誤って処理する可能性があります。これにより、重複排除が失敗し、重複した主キーが発生する可能性があります。

影響を受けたバージョン:

V2.2.13 以前。

修正済みバージョン:

V2.2.14 以降。

最新バージョンにアップグレードします。

P2

Flink を使用して Paimon からデータを読み取り、Hologres に書き込むと、VARCHAR データが文字化けして書き込まれる可能性があります。

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 値よりも大きいと見なす比較ルールを定義しています。しかし、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 以降。

• 1 つの SQL ステートメントの WHERE 句に、同じ主キー (pk) に対する複数のフィルター条件を含めないでください。

• 最新バージョンにアップグレードします。

P1

リバランス中にスキーマを変更すると、インスタンスが書き込みやクエリを処理できなくなる可能性があります。

リバランスは、レプリケーションの遅延が 10 秒未満の場合、シャードのリーダーとフォロワー間の切り替えをトリガーします。この切り替え中にユーザーがスキーマを変更すると、ストレージエンジンが異常な状態になり、インスタンスが書き込みやクエリ操作を処理できなくなります。Hologres V2.1 では、インスタンスに空のワーカーノードがある場合、システムが自動的にリバランスをトリガーするため、この問題が発生しやすくなります。

影響を受けたバージョン:

• V2.1.16 ～ V2.1.23

• V2.0.0 ～ V2.0.41

修正済みバージョン:

• V2.1.24 以降

• V2.0.42 以降

最新バージョンにアップグレードします。

P2

Hologres インスタンスを V2.1.25 以降にアップグレードした後、システムは非公開スキーマのテーブルに対して insert overwrite ステートメントによって生成された一時テーブルを自動的にクリーンアップできません。

insert overwrite ステートメントの実行中に検出が見落とされたため、一時テーブルが適切にクリーンアップされませんでした。

影響を受けたバージョン:

V2.1.25 ～ V2.1.32。

修正済みバージョン:

V2.1.33 以降。

• HoloWeb のテーブル管理機能を使用して、一時テーブルをワンクリックでクリーンアップします。

• 最新バージョンにアップグレードします。

P2

FixedFE (コネクタの jdbc_fixed モードに対応) を使用して Hologres にデータを書き込む際、SLPM モデルが有効で、ユーザーが指定されたスキーマの開発者権限を持っているにもかかわらず、FixedFE が permission denied for schema XXX エラーを報告します。

FixedFE は、SLPM モデルで権限が変更されたときにキャッシュを迅速に更新できませんでした。その結果、ユーザーがすでに必要な権限を持っているにもかかわらず、FixedFE はエラーを報告しました。

影響を受けたバージョン:

V2.0.31 以前

修正済みバージョン:

V2.0.32 以降

最新バージョンにアップグレードします。

レベル

説明

原因

バージョン

回避策

P2

datediff 関数を使用して指定された単位で 2 つの時間値の差を計算すると、返される結果が時々 1 ずれることがあります。

関数にロジックバグが含まれています。

影響を受けたバージョン:

V2.0.31。

修正済みバージョン:

V2.1.27 以降。

最新バージョンにアップグレードします。

P2

Hologres インスタンスを V2.1.26 にアップグレードした後、クエリのメモリ使用量メトリックがゆっくりと継続的に増加します。

V2.1.26 へのアップグレード後、クエリが OOM エラーに遭遇すると、そのメモリ使用量が複数回カウントされます。これにより、対応する監視メトリックが膨張して表示されます。

影響を受けたバージョン:

V2.1.26。

修正済みバージョン:

V2.1.27 以降。

最新バージョンにアップグレードします。

P1

Hologres インスタンスを V2.1 にアップグレードした後、MaxCompute 外部テーブルをクエリすると、メモリ使用量が徐々に増加したり、クエリパフォーマンスが変動したり、OOM エラーが増加したりする可能性があります。

V2.1 インスタンスで MaxCompute 外部テーブルをクエリすると、システムが開いているファイルを迅速に閉じません。これにより、メモリ使用量が徐々に増加し、クエリパフォーマンスとインスタンスの安定性に影響します。

影響を受けたバージョン:

V2.1.1 ～ V2.1.25。

修正済みバージョン:

V2.1.26 以降。

最新バージョンにアップグレードします。

P2

V2.1 では、プライマリ/セカンダリインスタンスおよび仮想ウェアハウスインスタンスのストレージ使用量が増加し、監視メトリクスからの合計使用量が pg_relation_size 関数の計算値を超えます。

システムが V2.1 プライマリ/セカンダリインスタンスまたは仮想ウェアハウスインスタンスから古いファイルを迅速に回収しません。これにより、ストレージが増加し、監視されるストレージ量が膨張します。

影響を受けたバージョン:

V2.1.1 ～ V2.1.25。

修正済みバージョン:

V2.1.26 以降。

最新バージョンにアップグレードします。

P1

Flink ジョブが JDBC モードで Hologres バイナリログを消費する際、起動時の消費率は高いですが、時間の経過とともに継続的に低下します。

Flink ジョブが JDBC モードで Hologres バイナリログを消費する際にメモリリークが発生します。

影響を受けたバージョン:

VVR V6.0.7 以前のバージョン。

修正済みバージョン:

VVR V6.0.7 以降。

最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P0

クエリリソースが解放されず、次の問題が発生します。

• メモリの継続的な増加。

• 多数のロックが保持される。

• リソースを割り当てられないため、多数のクエリが停止します。インスタンスを再起動しても問題は解決せず、クエリはすぐに再び停止します。

クエリがシャードデータのみを含み、PQE または SQE を使用して MaxCompute 外部テーブルまたはデータレイク外部テーブルをクエリする場合、クエリ完了後にシステムがリソースを自動的に解放しません。Query Master のガベージコレクションメカニズムのみがこれらのリソースを回収できます。Query Master が高負荷の場合、終了が遅れるとクエリ操作が過剰なリソースを保持し、後続のクエリをブロックします。

影響を受けたバージョン:

V2.1.23 ～ V2.1.24。

修正済みバージョン:

V2.1.25 以降。

最新バージョンにアップグレードします。

P1

辞書エンコードされた非 NULL 列にビットマップを追加すると、NULL 値を含む不正確な結果が返されます。

辞書エンコードされた列のビットマップを構築する際、バックエンドがすべてのデータにビットマップを適用できないため、不正確な結果が発生します。

影響を受けたバージョン:

V2.1.21 以前。

修正済みバージョン:

V2.1.22 以降。

最新バージョンにアップグレードします。

P1

Fixed Plan を使用してリアルタイムデータ書き込みやポイントクエリを行うと、インスタンスのメモリ使用量が徐々に増加します。

Hologres V2.1 では、Fixed Plan 実行エンジンがリファクタリングされました。読み書きテーブル用に作成されたオペレーターが迅速にクリーンアップされないため、メモリリークが発生します。

影響を受けたバージョン:

V2.1.1 ～ V2.1.9。

修正済みバージョン:

V2.1.10 以降。

最新バージョンにアップグレードします。

P1

PQE で実行中のクエリをキャンセルすると、対応する PQE ノードでプロセスデッドロックが発生し、新しい PQE リクエストを処理できなくなる可能性があります。

キャンセルシグナルを受信すると、PQE I/O 同時実行制御機能に不具合が発生する可能性があります。この問題はすべての PQE プロセスに影響します。

影響を受けたバージョン:

• V2.1.2 ～ V2.1.8。

• V2.0.23 ～ V2.0.30。

修正済みバージョン:

• V2.1.9 以降。

• V2.0.31 以降。

最新バージョンにアップグレードします。

P2

INTERSECT または EXCEPT 関数は、シャードプルーニングがアクティブな場合に不正確な結果を返します。たとえば、シャードプルーニングがアクティブな場合、次の 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 を使用して実装されています。シャードプルーニング中にこれらの関数を処理すると、不正確な実行プランが生成され、クエリ結果が不正確になる可能性があります。

影響を受けたバージョン:

V2.1.21 以前。

修正済みバージョン:

V2.1.22 以降。

最新バージョンにアップグレードします。

P2

PQE プロセスが終了する際、ハングすることがあります。これが時間とともに蓄積され、PQE が新しいリクエストを処理できなくなる可能性があります。

PQE プロセスが終了する際、RPC 終了スレッドとメインスレッド間の同時実行の問題により、RPC 終了スレッドが完了できなくなります。これにより、PQE プロセスが正常に終了できなくなります。

影響を受けたバージョン:

V2.1.0 ～ V2.1.14。

修正済みバージョン:

V2.1.15 以降。

最新バージョンにアップグレードします。

P2

PQE で同時クエリを実行すると、インスタンスが一時的に再起動することがあります。

Hologres V2.0 以前のバージョンでは、PQE にマルチスレッドの同時実行の問題があり、インスタンスのコアダンプを引き起こす可能性があります。

影響を受けたバージョン:

V2.0 以前。

修正済みバージョン:

V2.1.0 以降。

最新バージョンにアップグレードします。

P2

プリペアドステートメントモードで in ($1....) を含む SQL ステートメントを実行し、シャードセレクターによって処理されると、インスタンスが一時的に再起動する可能性があります。

オプティマイザーが不正確な実行プランを生成し、インスタンスのコアダンプを引き起こす可能性があります。

影響を受けたバージョン:

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. エラーが発生します。その後、BIGINT 型に変換する際、システムが BIT 型を誤って識別し、syntax error at or near ")" エラーが発生します。

影響を受けたバージョン:

V2.1.20 以前

修正済みバージョン:

V2.1.21 以降

最新バージョンにアップグレードします。

P2

主キーを持つ行指向テーブルのクラスタリングキーを空文字列に設定すると、メタデータの不整合が発生し、クエリがハングします。テーブル作成 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;

行指向テーブルのクラスタリングキーが空文字列で、主キーと異なる場合、FE ノードがリクエストに応答できなくなり、メタデータの不整合が発生してクエリがハングします。

影響を受けたバージョン:

V2.1.20 以前

修正済みバージョン:

V2.1.21 以降

• テーブルを再作成し、クラスタリングキーを明示的に指定します。最適なパフォーマンスを得るには、行指向テーブルのクラスタリングキーと主キーを一致させることを推奨します。

• 最新バージョンにアップグレードします。

P2

フィルター条件 (WHERE 句) にクラスタリングキーが含まれ、ORDER BY もそのキーでソートするために使用されている場合、クエリが不正確な結果を返します。例として、a 列がクラスタリングキーである WHERE a >= xxx LIMIT x ORDER BY a のようなクエリがあります。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 行を返す可能性があります。

フィルター条件にクラスタリングキーが含まれ、ORDER BY がそのクラスタリングキーでソートするために使用されている場合、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

--PostgreSQL の結果、正確
1.111111111100000000
1.111111111200000000
2.222222222200000000
2.222222222400000000

DECIMAL 型の乗算のデフォルトの精度は 18 です。2 つの DECIMAL 型の乗算結果が 18 桁を超える場合、システムは計算前にデータを切り捨てるため、不正確な結果になります。

影響を受けたバージョン:

V2.1.18 以前

修正済みバージョン:

V2.1.19 以降

• DECIMAL 型の値を TEXT 型に変換 (CAST) します。

• 最新バージョンにアップグレードします。

レベル

説明

原因

影響を受けたバージョンと修正済みバージョン

回避策

P2

Hologres V2.1 へのアップグレード後、truncate 操作に続く INSERT 操作を実行すると、時々 Invalid table id in schema エラーが発生します。

Hologres V2.1 では、FrontEnd コンポーネントがリプレイキャッシュ時間を過度に長く設定していました。これにより、DDL 操作に続く DML 操作の DDL リプレイが遅くなりました。

影響を受けたバージョン:

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 エラーで失敗します。例:

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

jsonb_to_textarray 関数を SQL ステートメントで定数と共に使用すると、不正確なプッシュダウンが発生し、エラーが発生します。

影響を受けたバージョン:

• V2.1.1 ～ V2.1.14。

• V2.0.34 以前。

修正済みバージョン:

• V2.1.15 以降。

• V2.0.35 以降。

最新バージョンにアップグレードします。

P2

regexp_split_to_array 関数を使用すると、時々 ERROR: Illegal udf8 string in xxxx エラーが発生します。

regexp_split_to_array 関数がメモリ境界を超えて読み取るため、クエリが失敗します。

影響を受けたバージョン:

V2.1.1 ～ V2.1.12。

修正済みバージョン:

V2.1.13 以降。

最新バージョンにアップグレードします。

P2

SELECT * FROM <table_name> LIMIT xxx; を使用したクエリが時々ハングすることがあります。

Hologres は LIMIT 句を含む全表スキャンに遅延読み込みを使用します。スキャンが一度に大量のデータを読み取るため、クエリがハングします。

影響を受けたバージョン:

• V2.1.1 ～ V2.1.11。

• V2.0.33 以前。

修正済みバージョン:

• V2.1.12 以降。

• V2.0.34 以降。

最新バージョンにアップグレードします。

P2

インスタンスの再起動、アップグレード、またはスケーリング後、Hologres 外部テーブルから直接読み取る MaxCompute タスクが時々ハングすることがあります。

インスタンスの再起動後、システムはテーブルメタデータを更新します。MaxCompute が直接読み取り中に更新されたメタデータステータスを時間内に取得できないため、タスクがハングします。

影響を受けたバージョン:

• V2.1.0 ～ V2.1.2。

• V2.0.5 以前。

修正済みバージョン:

• V2.1.3 以降。

• V2.0.26 以降。

最新バージョンにアップグレードします。