Hologres:Locks and lock troubleshooting

ロック動作の変更

• Hologres V2.0 以降、FE に対してデフォルトでロックフリーメカニズムが有効になっています。同じテーブルに対するデータ定義言語 (DDL) 文とデータクエリ言語 (DQL) 文が競合する場合、新しいリクエストは直ちにエラーを返します。たとえば、テーブル A で DDL 操作が実行中に新しいクエリリクエストが到着した場合、新しいリクエストは失敗します。エラーを返す代わりに、システムがロックの解放を待機するようにしたい場合は、次のコマンドを実行して Grand Unified Configuration (GUC) パラメーターを設定し、ロックフリーメカニズムを無効にできます。

  ALTER database <db_name> SET hg_experimental_disable_pg_locks = off;

• Hologres V2.1 以降、プライマリキーのないテーブルに対するバルクロード操作は、テーブルレベルロックの代わりに、行レベルロックのみを取得するように最適化されています。

ロックの概要

• FE ロック

  Hologres のフロントエンドは PostgreSQL と互換性があります。したがって、FE ロックは PostgreSQL のロックモデルに準拠しています。PostgreSQL は、同時データアクセスを制御するために、テーブルレベルロック、行レベルロック、勧告的ロックの 3 つのロックモードを提供します。Hologres は現在、テーブルレベルロックと勧告的ロックをサポートしています。

  説明

  Hologres は、明示的なロックコマンドや勧告的ロック関連のユーザー定義関数 (UDF) をサポートしていません。

  • テーブルレベルのロック

    • カテゴリ

      テーブルレベルロックはテーブル全体に適用されます。次の表に、テーブルレベルロックの種類を示します。

      ロック名	説明	注：
      アクセス共有	SELECT コマンドは、関連するテーブルに対してこのロックを取得します。	N/A
      行共有	SELECT FOR UPDATE および SELECT FOR SHARE コマンドは、ターゲットテーブルに対して ROW SHARE ロックを取得します。JOIN で関連付けられた他のテーブルなど、非ターゲットテーブルでは、これらのコマンドは ACCESS SHARE ロックのみを取得します。	Hologres は SELECT FOR UPDATE または SELECT FOR SHARE コマンドをサポートしていないため、このロックは使用されません。
      行排他	データを変更する UPDATE、DELETE、および INSERT 文がこのロックを取得します。	このロックを BE ロックと一緒に監視します。
      共有更新限定	このロックは、テーブルを同時スキーマ変更と `VACUUM` の実行から保護します。次のコマンドがこのロックを取得します。 Vacuum Full 以外の lazy VACUUM。 ANALYZE。 CREATE INDEX CONCURRENTLY。 説明 Hologres はこのコマンドに対して SHARE UPDATE EXCLUSIVE ロックを取得しません。代わりに、`CONCURRENTLY` オプションなしの CREATE INDEX コマンドと同様に、SHARE ロックを取得します。 CREATE STATISTICS。Hologres はこのコマンドをサポートしていません。 COMMENT ON。 ALTER TABLE VALIDATE CONSTRAINT。Hologres はこのコマンドをサポートしていません。 ALTER TABLE SET/RESET (storage_parameter)。Hologres は、拡張プロパティとネイティブ PostgreSQL の autovacuum_enabled プロパティを設定するためにのみ、このコマンドをサポートします。これらのプロパティを設定しても、テーブルロックは取得されません。他のいくつかの組み込み PostgreSQL storage parameter 値を変更するには、このロックが必要です。詳細については、「ALTER TABLE」をご参照ください。 ALTER TABLE ALTER COLUMN SET/RESET options。 ALTER TABLE SET STATISTICS。Hologres はこのコマンドをサポートしていません。 ALTER TABLE CLUSTER ON。Hologres はこのコマンドをサポートしていません。 ALTER TABLE SET WITHOUT CLUSTER。Hologres はこのコマンドをサポートしていません。	ANALYZE コマンドに注意してください。
      共有	非並行モードで実行される CREATE INDEX 文がこのロックを取得します。 説明 このロックは、Hologres で JSON インデックスを作成するときに必要です。	CREATE INDEX コマンドを使用して JSON 関連のインデックスを作成します。
      行排他共有	次のコマンドは、同時データ変更を防ぐためにロックを取得します。 CREATE COLLATION：Hologres はこの文をサポートしていません。 CREATE TRIGGER：Hologres はこの文をサポートしていません。 特定の ALTER TABLE 文。 DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER：Hologres はこの文をサポートしていません。 ADD table_constraint：Hologres はこの文をサポートしていません。	Hologres はこのロックを取得するコマンドをサポートしていないため、対応は不要です。
      独占	REFRESH MATERIALIZED VIEW CONCURRENTLY コマンドがこのロックを取得します。	Hologres は REFRESH MATERIALIZED VIEW CONCURRENTLY 文をサポートしていません。対応は不要です。
      排他アクセス	このロックは排他的アクセスを提供し、他のすべてのロックと競合します。次のコマンドがこのロックを取得します。 DROP TABLE TRUNCATE TABLE REINDEX：Hologres はこのコマンドをサポートしていません。 CLUSTER：Hologres はこのコマンドをサポートしていません。 VACUUM FULL REFRESH MATERIALIZED VIEW (without CONCURRENTLY)：Hologres はこのコマンドをサポートしていません。 LOCK：明示的な `LOCK` コマンド。ロックタイプを指定しない場合、このロックがデフォルトで取得されます。Hologres はこのコマンドをサポートしていません。 ALTER TABLE：デフォルトでは、他の特定のロックを取得すると明示的に記載されている ALTER TABLE フォームを除き、他のすべての ALTER TABLE コマンドがこのロックを取得します。	これは重大なロックです。Hologres のすべての DDL 操作がこのロックを取得します。他のすべてのロックと競合します。

    • タイムアウト

      デフォルトでは、FE ロックはタイムアウトしません。FE ロックのタイムアウト期間を指定して待機時間を制御する場合は、クエリの管理を参照してください。

    • 競合関係

      次の表にロックの競合を示します。競合とは、ある操作がロックを保持している場合、競合するロックを要求する別の操作が待機しなければならないことを意味します。

      説明

      競合なしは競合がないことを示します。競合ありは競合があることを示します。

      要求されたロックモード	ACCESS SHARE	ROW SHARE	ROW EXCLUSIVE	SHARE UPDATE EXCLUSIVE	SHARE	SHARE ROW EXCLUSIVE	EXCLUSIVE	ACCESS EXCLUSIVE
      ACCESS SHARE	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象外
      ROW SHARE	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象外	サポート対象外
      ROW EXCLUSIVE	サポート対象	サポート対象	サポート対象	サポート対象	サポート対象外	サポート対象外	サポート対象外	サポート対象外
      SHARE UPDATE EXCLUSIVE	サポート対象	サポート対象	サポート対象	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外
      SHARE	サポート対象	サポート対象	サポート対象外	サポート対象外	サポート対象	サポート対象外	サポート対象外	サポート対象外
      SHARE ROW EXCLUSIVE	サポート対象	サポート対象	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外
      EXCLUSIVE	サポート対象	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外
      ACCESS EXCLUSIVE	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外

  • アドバイザリ ロック

    勧告的ロックは、PostgreSQL が提供するアプリケーション定義のロックです。ほとんどの Hologres のユースケースでは、勧告的ロックについて気にする必要はありません。

• BE ロック

  • カテゴリ

    Hologres は次の BE ロックカテゴリを使用します。

    ロックカテゴリ	ロックの概要
    排他(X)	トランザクションは、1 つ以上のデータエントリを変更するために排他ロック (相互排他ロックとも呼ばれる) を要求します。たとえば、DELETE、INSERT、UPDATE などのデータ操作言語 (DML) 文には排他ロックが必要です。排他ロックは、他の共有ロックまたは排他ロックが存在しない場合にのみリソースに付与できます。排他ロックが付与されると、そのリソースに他のロックをかけることはできません。
    共有(S)	トランザクションは、1 つ以上のデータエントリを読み取るために共有ロックを要求します。このロックは、他のトランザクションがデータを変更するのを防ぎます。リソースは複数の共有ロックを持つことができます。したがって、DQL 文はリソースを変更しないため、複数の DQL 文を同時にリソースで実行できます。
    インテント(I)	インテントロックはロック階層を定義します。単一のリソースは複数のインテントロックを持つことができます。リソースがインテントロックを持つと、そのリソースに排他ロックをかけることはできません。たとえば、トランザクションが行に対して排他ロックを要求する場合、テーブルに対してもインテントロックを要求する必要があります。これは、テーブルが行よりも上位レベルのリソースであるためです。テーブルのインテントロックは、他のトランザクションがそのテーブルに排他ロックをかけるのを防ぎます。

  • タイムアウト

    BE ロックのデフォルトのタイムアウトは 5 分です。ロック待機がこの期間を超えるとエラーが発生します。

  • 人間関係の対立

    次の表に BE ロックの競合を示します。競合とは、ある操作がロックを保持している場合、競合するロックを要求する他の操作が待機しなければならないことを意味します。

    説明

    競合なしは競合がないことを示します。競合ありは競合があることを示します。

    操作	DROP	ALTER	SELECT	UPDATE	DELETE	INSERT (INSERT ON CONFLICT を含む)
    DROP	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外	サポート対象外
    ALTER	サポート対象外	サポート対象外	サポート済み	サポート対象外	サポート対象外	サポート対象外
    SELECT	サポート対象外	サポート済み	サポート済み	サポート済み	サポート済み	サポート済み
    UPDATE	サポート対象外	サポート対象外	サポート済み	サポート対象外	サポート対象外	サポート対象外
    DELETE	サポート対象外	サポート対象外	サポート済み	サポート対象外	サポート対象外	サポート対象外
    INSERT (including INSERT ON CONFLICT)	サポート対象外	サポート対象外	サポート済み	サポート対象外	サポート対象外	サポート対象外

ロックのスコープ

トランザクション関連のロック

Hologres は明示的な DDL トランザクションのみをサポートします。純粋な DML トランザクションや混合 DDL/DML トランザクションはサポートしていません。

• Hologresはネストされたサブトランザクションをサポートしていません。

• 純粋な DML トランザクションは構文チェックをパスしますが、アトミックコミットやロールバックはサポートしていません。

  次の DML の例では、insert 操作が成功しても、後続の update 操作が失敗した場合、insert 操作のデータはロールバックされません。

  begin;
  insert into t1(id, salary) values (1, 0);
  update t1 set salary = 0.1 where id = 1;
  commit;

• 純粋な DDL トランザクションは期待どおりに機能します。

  DDL 文の 1 つが失敗すると、トランザクション全体がロールバックされます。たとえば、次の ALTER 文が失敗した場合、CREATE 文と DROP 文もロールバックされます。

  begin;
  create table t1(i int);
  drop table if exists t2;
  alter table t1 add column n text;
  commit;

• 混合 DDL および DML トランザクションは許可されていません。

  次の例では、トランザクションに DDL 文と DML 文の両方を含めると、DML 文が失敗します。

  begin;
  create table t1(i int);
  update t1 set i = 1 where i = 1;
  -- DML statement error
  ERROR:  UPDATE in ddl transaction is not supported now.

• 明示的なトランザクション内の任意のコマンドによって取得されたロックは、トランザクション全体がコミットまたはロールバックによって終了した場合にのみ解放されます。

  たとえば、親テーブルで ALTER 操作を実行すると、親テーブル (login_history) と子テーブル (login_history_202001) の両方で ACCESS EXCLUSIVE ロックが取得されます。ただし、ロックはコマンドの完了直後には解放されません。代わりに、コマンドが成功したか失敗したかに関係なく、最終的な COMMIT コマンドが実行された後にのみロックが解放されます。COMMIT コマンドが実行されない場合、ロックは無期限に保持されます。この場合、このテーブルに対する他の DDL 操作はブロックされ、エラーが発生します。

   -- suppose we have three tables
  create table temp1(i int, t text);
  create table login_history(ds text, user_id bigint, ts timestamptz) partition by list (ds);
  create table login_history_202001 partition of login_history for values in ('202001');
  
  begin;
  alter table login_history_s1 add column user_id bigint;
  drop table temp1;
  create table tx2(i int);
  commit;

FE ロックのトラブルシューティング

次の手順に従って、FE ロックを確認および解決できます。

1. クエリの実行に時間がかかる場合は、wait_event_type フィールドをチェックして、現在のクエリがロックされているかどうかを判断できます。

   次のコマンド例では、結果の wait_event_type フィールドの値が lock の場合、クエリは FE ロックによってブロックされています。

   -- Hologres V2.0 以降:
   select query,state,query_id,transaction_id,pid,wait_event_type,wait_event,running_info,extend_info FROM hg_stat_activity where query_id = 200640xxxx;
   -- 次の結果が返されます。
   ----------------+----------------------------------------------------------------
   query           | drop table test_order_table1;
   state           | active
   query_id        | 200640xxxx
   pid             | 123xx
   transaction_id  | 200640xxxx
   wait_event_type | Lock
   wait_event      | relation
   running_info    | {"current_stage":{"stage_duration_ms":47383,"stage_name":"PARSING"},"fe_id":1,"warehouse_id":0}+
                   |
   extend_info     | {}                                                                                                                                           +
   
   -- Hologres V1.3 以前:
   select datname, pid, application_name, wait_event_type, state,query_start, query from pg_stat_activity where backend_type in ('client backend');
   -- 次の結果が返されます。
   ----------------+----------------------------------------------------------------
   datname           | holo_poc
   pid               | 321xxx
   application_name  | PostgreSQL JDBC Driver
   wait_event_type   | lock
   state             | active
   query_start       |2023-04-20 14:31:46.989+08
   query             | delete from xxx

2. ロックの所有者を表示します。

   次のコマンドを実行して、ロックホルダーを表示できます。

   select * from pg_locks where pid = <pid>;

   上記のコマンドで、pid をステップ 1 で返された pid の値に設定します。

3. ロックを保持しているプロセスを特定します。

   ステップ 2 から現在の SQL 文にロックがあると判断した場合、次のコマンドとその oid (テーブルリレーション) を使用して、ロックが保持されているかどうかを確認できます。このコマンドでは、t は true を表し、ロックが保持されていることを示します。

   -- テーブルロックを保持しているプロセスをクエリします。
   select pid from pg_locks where relation = <OID> and granted = 't';

4. ロックを保持しているクエリを特定します。

   ステップ 3 の PID を使用して、次のコマンドを実行し、ロックを保持しているクエリを見つけることができます。

   select * from pg_stat_activity where pid = <PID>;

5. ロックを解放します。

   ロックを保持しているクエリを特定した後、次のコマンドを実行してクエリを終了し、ロックを解放できます。

   select pg_cancel_backend(<pid>);

BE ロックのトラブルシューティング

hg_stat_activity ビューの be_lock_waiters フィールドが空でない場合、クエリは BE ロックを取得しているか、バックエンドで BE ロックが解放されるのを待っています。次の手順を使用して BE ロックを確認できます。

• シナリオ 1：現在のクエリがロックを保持し、他のクエリがその解放を待機している。

  次の SQL 文を実行して、現在のクエリが BE ロックを保持しているかどうか、およびどのクエリがそれを待機しているかを確認できます。

  select query_id, transaction_id, ((extend_info::json)->'be_lock_waiters'->>0)::text as be_lock_waiters 
  FROM hg_stat_activity as h where h.state = 'active' and ((extend_info::json)->'be_lock_waiters')::text != '';
  
  -- 次の結果が返されます。
  ----------------+------------------
  query_id        | 10005xxx
  transaction_id  | 10005xxx
  be_lock_waiters | 13235xxx

• シナリオ 2：ブロッキングしているクエリを特定し、それがロックを解放するのを待つ。

  次の SQL 文を実行して、現在のクエリが待機しているロックを保持しているクエリを見つけることができます。

  select query_id, transaction_id, ((extend_info::json)->'be_lock_waiters')::text as be_lock_waiters 
  FROM hg_stat_activity as h where h.state = 'active' and ((extend_info::jsonb)->'be_lock_waiters')::jsonb ? '10005xxx';
  
  -[ RECORD 1 ]---+------------------------------------------
  query_id        | 200740017664xxxx
  transaction_id  | 200740017664xxxx
  be_lock_waiters | ["200640051468xxxx","200540035746xxxx"]

FAQ（よくある質問）

• エラー：internal error: Cannot acquire lock in time, current owners: [(Transaction =302xxxx, Lock Mode = SchS|SchE|X)].。

  • 考えられる原因：クエリ対象のテーブルが、別のクエリによって BE ロックでロックされています。これにより、現在のクエリは 5 分後にタイムアウトします。たとえば、エラー Lock Mode = SchS|SchE|X は、スキーマ安定性ロック、存在ロック、または排他ロックを示します。

  • 解決策：エラーメッセージ内の transaction (例：Transaction =302xxxx) はクエリ ID です。クエリ ID を使用して、スロークエリログまたはアクティブなクエリでロックを保持しているクエリを見つけることができます。

• エラー：ERROR: The schema version update timed out because the server's current version (xxx) is older than the requested version (yyy)。

  • 考えられる原因：DDL 文が FE ノードで実行された後、ストレージエンジン (SE) で非同期に実行されます。FE ノードは DDL 操作が完了するとすぐにバージョンを更新します。SE が DDL 操作を完了していない場合、そのバージョンは FE バージョンより遅れます。クエリは SE が追いつくのを待ちます。このプロセスが 5 分以上かかると、エラーが発生します。

  • ソリューション:

    • 待機中の DDL 文を強制終了し、クエリを再試行します。

    • インスタンスを再起動します。これは最終手段としてのみ使用してください。

• エラー: リクエストされたテーブル名: xxx (id: 10, version: 26) は、サーバー上のテーブル (id: 10, version: 28) のバージョンと一致しません。

  • 考えられる原因：DDL 操作は、まず 1 つの FE ノードで実行され、次に SE で非同期に実行されます。SE は操作を完了してバージョンを更新しますが、複数の FE ノード間でのリプレイはまだ完了していません。一部の FE ノードは古いバージョンを持っています。クエリがこれらのノードのいずれかにルーティングされると、エラーが発生します。

  • ソリューション:

    • クエリを数回再試行します。

    • 数分経ってもエラーが続く場合は、インスタンスを再起動します。

• エラー：internal error: Cannot find index full ID: 86xxx (table id: 20yy, index id: 1) in storages or it is deleting!。

  • 考えられる原因：DROP Table または Truncate Table 操作が実行されると、テーブルに DDL ロックが取得されます。同じテーブルに対する SELECT や DELETE などの DML クエリは、ロックを待機する必要があります。DDL 操作が完了してテーブルが削除されると、待機中のクエリは失敗し、エラーを報告します。

  • 解決策：テーブルに対して DROP または TRUNCATE コマンドを実行するときは、そのテーブルに対して他のクエリを実行しないでください。