Hologres:ロックとロックのトラブルシューティング

ロック動作の変更

• Hologres V2.0 以降では、FE に対してロックフリーメカニズムがデフォルトで有効になっています。同じテーブルに対するデータ定義言語 (DDL) ステートメントとデータクエリ言語 (DQL) ステートメントが競合する場合、新しいリクエストに対してエラーメッセージが返されます。たとえば、DDL ステートメントが実行されているテーブル A に対してクエリリクエストが送信された場合、クエリリクエストに対してエラーメッセージが返されます。エラーメッセージを報告するのではなく、テーブル A のロックが解除された後にクエリリクエストを処理するようにシステムを設定する場合は、GUC パラメーターを off に設定してロックフリーメカニズムを無効にすることができます。

  ALTER database <db_name> SET hg_experimental_disable_pg_locks = off;

• Hologres V2.1 以降では、プライマリキーのないテーブルに対する bulkload ステートメントが最適化されています。最適化後、プライマリキーのないテーブルに対する bulkload ステートメントは、行レベルのロックのみを取得します。

ロックの概要

• FE ロック

  Hologres の FE は PostgreSQL と互換性があります。したがって、FE ロックは PostgreSQL と互換性があります。 PostgreSQL は、同時アクセスを制御できるように、テーブルレベルロック、行レベルロック、およびアドバイザリロックの次のタイプのロックを提供します。 Hologres は、PostgreSQL によって提供されるテーブルレベルロックとアドバイザリロックと互換性があります。

  説明

  Hologres は、明示的なロックステートメント、またはアドバイザリロックに関連するユーザー定義関数（UDF）をサポートしていません。

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

    • カテゴリ

      次の表は、テーブルレベルのロックについて説明しています。

      名前	説明	備考
      アクセス共有	ほとんどの場合、テーブルに対する ACCESS SHARE ロックは、テーブルのクエリに使用される SELECT ステートメントによってのみ取得されます。	N/A.
      行共有	The ROW SHARE lock on a table is acquired only by the SELECT FOR UPDATE および SELECT FOR SHARE ステートメントによってのみ取得されます。これらのステートメントは、テーブルのクエリに使用されます。 JOIN を使用してクエリ対象のテーブルと結合されるテーブルなど、他の関連テーブルについては、これらのステートメントは ACCESS SHARE ロックのみを取得します。	Hologres は、SELECT FOR UPDATE または SELECT FOR SHARE ステートメントをサポートしていません。そのため、このロックに注意する必要はありません。
      行排他	テーブルの行排他ロックは、テーブルのデータを変更するために実行される UPDATE、DELETE、および INSERT ステートメントによって取得されます。	ROW EXCLUSIVE ロックを管理する場合は、BE ロックにも注意する必要があります。
      共有更新限定	SHARE UPDATE EXCLUSIVE ロックは、同時スキーマ変更およびバキューム実行からテーブルを保護するために使用されます。SHARE UPDATE EXCLUSIVE ロックは、次のステートメントによって取得されます。 lazy VACUUMではなく、VACUUM Fullを使用します。 ANALYZE. CREATE INDEX CONCURRENTLY。 説明 SHARE UPDATE EXCLUSIVE ロックは、Hologres でこのステートメントを実行しても取得されません。代わりに、このステートメントは、非同時実行モードで実行される SHARECREATE INDEX ステートメントと同じ方法で ロックを取得します。 CREATE STATISTICS: Hologres はこのステートメントをサポートしていません。 COMMENT ON。 ALTER TABLE VALIDATE CONSTRAINT: Hologres はこのステートメントをサポートしていません。 ALTER TABLE SET/RESET (storage_parameter): Hologresでは、このステートメントを実行して、拡張属性とPostgreSQLネイティブ属性autovacuum_enabledのみを構成できます。上記の属性を構成するために実行されるこのステートメントは、テーブルのロックを取得しません。 PostgreSQLの特定の組み込みストレージ パラメーターを変更するステートメントを実行すると、このロックが取得されます。詳細については、ALTER TABLEをご参照ください。 ALTER TABLE ALTER COLUMN SET/RESET オプション。 ALTER TABLE SET STATISTICS: Hologres はこのステートメントをサポートしていません。 ALTER TABLE CLUSTER ON: Hologres はこのステートメントをサポートしていません。 ALTER TABLE SET WITHOUT CLUSTER: Hologres はこのステートメントをサポートしていません。	ANALYZE ステートメントに注意してください。
      共有	CREATE INDEX 文が非同時実行モードで実行された場合のみ、SHARE ロックが取得されます。 説明 Hologres で JSON インデックスを作成する場合は、SHARE ロックが必要です。	CREATE INDEX ステートメントを使用して JSON インデックスを作成することに注意してください。
      行排他共有	SHARE ROW EXCLUSIVE ロックは、同時データ変更からテーブルを保護するために使用されます。SHARE ROW EXCLUSIVE ロックは、次のステートメントによって取得されます。 CREATE COLLATION: Hologres はこのステートメントをサポートしていません。 CREATE TRIGGER: Hologres はこのステートメントをサポートしていません。 Specific ALTER TABLE ステートメント。 DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER: Hologres はこのステートメントをサポートしていません。 ADD table_constraint: Hologres はこのステートメントをサポートしていません。	Hologres では、SHARE ROW EXCLUSIVE ロックを取得するステートメントはサポートされていません。そのため、このロックについて注意する必要はありません。
      独占	REFRESH MATERIALIZED VIEW CONCURRENTLY 文のみが EXCLUSIVE ロックを取得します。	Hologres は REFRESH MATERIALIZED VIEW CONCURRENTLY ステートメントをサポートしていません。そのため、このロックに注意する必要はありません。
      排他アクセス	ACCESS EXCLUSIVEロックは、排他アクセスを確保するために使用されます。このロックは、他のすべてのロックと競合します。ACCESS EXCLUSIVEロックは、次のステートメントによって取得されます。 DROP TABLE TRUNCATE TABLE REINDEX: Hologres はこのステートメントをサポートしていません。 CLUSTER: Hologres はこのステートメントをサポートしていません。 VACUUM FULL REFRESH MATERIALIZED VIEW (without CONCURRENTLY): Hologres はこのステートメントをサポートしていません。 LOCK: 明示的なロックステートメントです。ロックタイプを指定しない場合、ACCESS EXCLUSIVEロックが取得されます。Hologres はこのステートメントをサポートしていません。 ALTER TABLE: デフォルトでは、すべての ALTER TABLE ステートメントは、特定のロックを取得する上記の ALTER TABLE ステートメントを除き、ACCESS EXCLUSIVE ロックを取得します。	ACCESS EXCLUSIVE ロックに注意する必要があります。このロックは、Hologres のすべての DDL ステートメントによって取得され、他のすべてのロックと競合します。

    • タイムアウト

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

    • ロックの競合

      次の表は、異なるロック間の競合について説明しています。2 つのロックが互いに競合し、操作によってリソースのいずれかのロックが取得された場合、同じリソースのもう一方のロックを取得する他の操作は、現在のロックが解放されるまで待機する必要があります。

      説明

      は、2 つのロックが互いに競合しないことを示し、 は、2 つのロックが互いに競合することを示します。

      要求されたロック モード	アクセス共有	行共有	行排他ロック	限定共有アップデート	共有	行共有排他	限定	限定アクセス
      アクセス共有
      行共有
      行排他
      共有更新限定
      共有
      行排他共有
      独占
      排他アクセス

  • アドバイザリ ロック

    PostgreSQLは、アプリケーションによって定義されるアドバイザリロックを作成する方法を提供しています。ほとんどの場合、Hologresを使用する際にアドバイザリロックに注意を払う必要はありません。

• BE ロック

  • カテゴリ

    次の表は、Hologresで使用されるBEロックのカテゴリについて説明しています。

    カテゴリ	説明
    排他(X)	排他ロックは、トランザクションが 1 つ以上のデータエントリを変更するときに要求されます。たとえば、DELETE、INSERT、UPDATE ステートメントなどのデータ操作言語 (DML) ステートメントは、排他ロックを要求します。リソースに対する排他ロックは、リソースに対して排他ロックまたは共有ロックが保持されていない場合にのみ、正常に要求できます。リソースに対する排他ロックが正常に要求された後、そのリソースに対して他のロックを要求することはできません。
    共有(S)	共有ロックは、トランザクションが 1 つ以上のデータエントリを読み取るときに要求されます。共有ロックは、読み取られるデータエントリを、他のトランザクションによってコミットされるデータ変更から保護します。リソースは複数の共有ロックをサポートします。このように、データクエリ言語 (DQL) ステートメントはリソースを変更しないため、複数の DQL ステートメントを同じリソースで同時に実行できます。
    インテント(I)	インテント ロックは、ロック階層を示すために使用されます。リソースは複数のインテント ロックをサポートします。リソースのインテント ロックが正常に要求されると、そのリソースに対して排他ロックを要求することはできません。たとえば、トランザクションが行の排他ロックを要求する場合、トランザクションはその行を含むテーブルのインテント ロックも要求します。テーブルは行よりも上位の階層にあります。このようにして、他のトランザクションはテーブルの排他ロックを要求できません。

  • タイムアウト

    BEロックのデフォルトのタイムアウト期間は 5 分です。BEロックがタイムアウトすると、エラーが返されます。

  • ロックの競合

    次の表は、異なる操作間の BE ロックの競合について説明しています。2 つの操作が互いに競合し、一方の操作がリソースのロックを取得した場合、リソースに対するもう一方の操作は、現在のロックが解除された後にのみサポートされます。

    説明

    は、2 つの操作が互いに競合しないことを示し、 は、2 つの操作が互いに競合することを示します。

    操作	削除	変更	SELECT	更新	削除	INSERT（INSERT ON CONFLICT を含む）
    DROP
    変更
    SELECT
    更新
    DETELE
    INSERT (競合が発生した場合の INSERT を含む)

ロックのスコープ

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

Hologres は、DDL ステートメントを使用する明示的なトランザクションのみをサポートしています。Hologres は、DML ステートメントのみを使用するトランザクション、または DDL ステートメントと DML ステートメントを同時に使用するトランザクションはサポートしていません。

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

• Hologres は DML ステートメントのみを使用するトランザクションの構文と互換性がありますが、トランザクションのアトミックコミットまたはロールバックはサポートしていません。

  たとえば、次の DML ステートメントでは、INSERT 操作が成功しても、UPDATE 操作が失敗した場合、inserted データはロールバックされません。

  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 ロックが取得されます。ALTER 操作が完了した後も、ロックは解放されません。ACCESS EXCLUSIVEcommit 操作が成功したかどうかに関係なく、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 ロックが存在するかどうかを確認する方法と、FE ロックの問題をトラブルシューティングする方法について説明します。

1. クエリに長時間を要する場合は、wait_event_type フィールドの値を確認して、クエリ文が FE ロックを取得しているかどうかを確認します。

   次の例では、返された結果の 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. FE ロックの所有者を表示します。

   FE ロックの所有者を表示するには、次のステートメントを実行します。

   select * from pg_locks where pid = <pid>;

   上記のステートメントでは、pid を手順 1 で返された pid 値に設定します。

3. FE ロックを保持しているプロセスを確認します。

   ステップ 2 の戻り値は、SQL ステートメントが FE ロックを取得したことを示しています。FE ロックを保持しているプロセスを確認するには、次のステートメントを実行します。このステートメントでは、relation をテーブル関係を示す オブジェクト ID（OID） に設定します。object ID (OID)granted を に設定します。これは、FE ロックが保持されていることを示します。

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

4. FE ロックを保持しているクエリを確認します。

   次のステートメントを実行して、FE ロックを保持しているクエリを確認します。このステートメントでは、pid を手順 3 で取得した pid 値に設定します。

   select * from pg_stat_activity where pid = <PID>;

5. FE ロックを解除します。

   FE ロックを保持しているクエリを特定した後、次のステートメントを実行してクエリを終了します。これにより、FE ロックが解放されます。

   select pg_cancel_backend(<pid>);

BEロックを確認する

hg_stat_activity ビューの be_lock_waiters フィールドが空でない場合、クエリは BE ロックを取得するか、バックエンドで BE ロックが解除されるのを待機しています。このセクションでは、BE ロックを確認する方法について説明します。

• シナリオ 1：現在のクエリが BE ロックを生成し、他のクエリが BE ロックの解放を待機しています。

  次のステートメントを実行して、現在の SQL ステートメントが BE ロックを取得しているかどうかを確認し、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：現在のクエリは、別のクエリによって BE ロックが解放されるのを待機しています。

  BEロックを保持しているクエリを取得するには、次のステートメントを実行します。現在のクエリは、BEロックが解放されるのを待機しています。

  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)]. エラーメッセージが報告された場合はどうすればよいですか？

  • Possible cause: The table from which you want to query data is locked by another query with a BE lock. In this example, the Lock Mode = SchS|SchE|X error message is returned, indicating that the queried table is locked with an SchS lock, SchE lock, or SchX lock. As a result, the current query needs to wait the BE lock to be released and times out. The timeout period is 5 minutes. 考えられる原因: データをクエリする対象のテーブルが、BE ロックを持つ別のクエリによってロックされています。この例では、Lock Mode = SchS|SchE|X エラーメッセージが返されます。これは、クエリ対象のテーブルが SchS ロック、SchE ロック、または SchX ロックでロックされていることを示しています。その結果、現在のクエリは BE ロックが解放されるまで待機する必要があり、タイムアウトになります。タイムアウト期間は 5 分です。

  • 解決策: クエリ ID を使用して、スロークエリログまたはアクティブなクエリで BE ロックを保持しているクエリを見つけます。 クエリ ID は、transactionTransaction =302xxxx で指定されている ID です。

• ERROR: Operation timed out: Wait schema version timeout.: Server current target schema version:xxx is late from request schema version: yyy エラーメッセージが報告された場合はどうすればよいですか？

  • 考えられる原因: DDL ステートメントが FE ノードで実行され、その後、ストレージエンジンによって非同期的に実行されます。FE ノードが DDL ステートメントを完了した後、FE ノードはノードバージョンを更新します。この場合、ストレージエンジンがまだ DDL ステートメントを実行している場合、ストレージエンジンのバージョンは FE ノードのバージョンよりも前になります。その結果、クエリはストレージエンジンが DDL ステートメントを完了するまで待機する必要があります。ストレージエンジンが 5 分以内に DDL ステートメントを完了できない場合、このエラーが返されます。

  • ソリューション:

    • ロックの解放を待機している DDL ステートメントを終了し、クエリを再送信します。

    • インスタンスを再起動します。これは最終手段です。

• The requested table name: xxx (id: 10, version: 26) mismatches the version of the table (id: 10, version: 28) from server というエラーメッセージが表示された場合はどうすればよいですか？

  • 考えられる原因: DDL ステートメントが FE ノードで実行され、その後、ストレージエンジンによって非同期的に実行されます。ストレージエンジンは DDL ステートメントを完了し、バージョンを更新しました。ただし、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 ロックが解放されるまで待機する必要があります。 DDL ロックが解放されると、テーブルは削除されます。その結果、このエラーメッセージが返されます。

  • Solution: DROP 操作または TRUNCATE 操作をテーブルで実行しているときは、そのテーブルに対して他のクエリを送信しないでください。