すべてのプロダクト
Search
ドキュメントセンター

Hologres:テーブルのゴミ箱

最終更新日:Jan 28, 2026

Hologres はテーブルのゴミ箱機能を提供します。DROP TABLE コマンドを使用してテーブルを削除すると、そのテーブルは自動的にゴミ箱に移動されます。これにより、削除されたテーブルを復元し、誤操作によるデータ損失を防ぐことができます。

制限事項

  • テーブルのゴミ箱機能は、Hologres V3.1 以降のインスタンスでのみ利用できます。

  • ゴミ箱内のテーブルは引き続きメモリを消費します。そのため、ベクターインデックスを持つテーブルに対してゴミ箱機能を有効にしないでください。詳細については、「Proxima Graph インデックスの使用ガイド」をご参照ください。

仕組み

DROP TABLE [CASCADE] または DROP DYNAMIC TABLE [CASCADE] コマンドを使用して内部テーブル、パーティションテーブル (親テーブルと子テーブルの両方)、または動的テーブルを削除すると、Hologres はそれらを自動的にテーブルのゴミ箱に移動します。

ゴミ箱内のテーブルは hg_recyclebin という名前の別のスキーマに格納されます。テーブル名、データ、プロパティ、およびインデックスは保持されます。

説明
  • TRUNCATE または INSERT OVERWRITE コマンドを実行した場合、テーブルはゴミ箱に移動されません。

  • 外部テーブル、ビュー、マテリアライズドビューはゴミ箱に移動されません。

  • テーブルに生存時間 (TTL) が設定されている場合、その TTL はゴミ箱内でも有効です。システムは TTL に基づいて定期的にテーブルデータをクリアします。

ゴミ箱の有効化または無効化

-- データベースのゴミ箱を有効にします。
ALTER DATABASE <db_name> SET hg_enable_recyclebin = ON; 

-- データベースのゴミ箱を無効にします。
ALTER DATABASE <db_name> SET hg_enable_recyclebin = OFF; 
説明
  • テーブルのゴミ箱機能は、V3.1 以降の新規および既存のインスタンスでデフォルトで有効になっています。

  • ゴミ箱を無効にした後でも、すでにゴミ箱にあるテーブルを回復またはパージすることはできます。ただし、機能を無効にした後に削除したテーブルはゴミ箱に移動されません。

  • 現在のインスタンスのスーパーユーザーのみがこの SQL コマンドを実行できます。このコマンドは、各 DB に対して一度だけ実行する必要があります。

テーブルの回復

次のコマンドを使用して、削除されたテーブルを回復できます。同じ名前のテーブルが存在する場合、table_id (V3.1.18 以降でサポート) または id (すべてのバージョンでサポート) を指定して、回復したいテーブルを特定できます。

RECOVER TABLE <table_name>;

-- 同じ名前のテーブルが存在する場合、table_id を指定して回復します (V3.1.18 以降)。
RECOVER TABLE <table_name> WITH (table_id = xxxx); 

-- 一般的な構文 (すべてのバージョン)。
RECOVER TABLE <table_name> [WITH (id = xxxx)];

次の点にご注意ください:

  • テーブルを回復する場合

    テーブルのデータ、プロパティ、およびプライマリキー (PK)、クラスタリングキー、セグメントキーなどのインデックスが回復されます。テーブルに TTL が設定されている場合、TTL は有効なままであり、システムは TTL に基づいて定期的にデータをクリアします。

  • テーブルを回復する前に

    • スキーマ内に同じ名前のテーブルがすでに存在する場合、既存のテーブルを削除または名前変更する必要があります。そうしないと、RECOVER コマンドは失敗します。ただし、既存のテーブルに PK またはクラスタリングキーがある場合は、RECOVER コマンドを実行する前に、それを別のスキーマに移動する必要があります。詳細については、「」をご参照ください。

    • テーブルが属していたスキーマが削除されている場合、回復操作は失敗します。

  • パーティションテーブルの場合

    • 回復された子テーブルは標準テーブルになります。手動で親テーブルにアタッチする必要があります。

    • 親テーブルを回復すると、親テーブルとその子テーブルの両方が元のパーティション構造に復元されます。子テーブルを手動でアタッチする必要はありません。

    • 親テーブルで動的パーティショニングが有効になっていた場合、回復後に自動的に設定されません。手動で有効にする必要があります。詳細については、「動的パーティショニング」をご参照ください。

  • 動的テーブルの場合

    • 回復された動的テーブルは標準テーブルになります。そのデータをクエリすることはできますが、テーブルは自動的に更新されなくなります。自動更新機能が必要な場合は、動的テーブルを再作成する必要があります。詳細については、「ALTER DYNAMIC TABLE」をご参照ください。

    • ベーステーブルを回復しても、その依存する動的テーブルは回復されません。

  • カスケードシナリオの場合

    DROP TABLE xxx CASCADE コマンドを使用してテーブルを削除すると、ビューやマテリアライズドビューなどの依存オブジェクトも削除されます。テーブルを回復すると、ターゲットテーブルのみが回復されます。ビュー、マテリアライズドビュー、および動的テーブルは回復されません。依存する動的テーブルも回復されません。

    例えば、動的テーブルが view1 に依存し、view1 が table1 に依存すると仮定します。DROP TABLE table1 CASCADE コマンドは、動的テーブルと view1 の両方を削除します。RECOVER コマンドを実行した後、動的テーブルと view1 は回復されず、手動で再作成する必要があります。

  • テーブルを回復する権限

    RECOVER コマンドを実行するには特定の権限が必要です。詳細については、「権限」をご参照ください。

ゴミ箱の管理

サポートされる操作

ゴミ箱内のテーブルでは、次の操作がサポートされています:

  • RECOVER (テーブルの回復) と PURGE (テーブルのパージ)。

  • hologres.hg_recyclebin を使用したテーブル詳細の表示。

テーブル詳細の表示

次の文を実行して、ゴミ箱内のテーブルの詳細を表示できます:

説明

テーブルオーナーは、ゴミ箱内で自分が所有するテーブルのみを表示できます。他のユーザーが所有するテーブルは表示できません。スーパーユーザーは、ゴミ箱内のすべてのテーブルを表示できます。

SELECT * FROM hologres.hg_recyclebin;

返される情報のパラメーターを次の表に示します。

パラメーター名

説明

table_id

ゴミ箱内のテーブルの一意の ID。テーブルを識別するために使用されます。

schema_name

削除される前にテーブルが配置されていたスキーマ。

table_name

削除されたテーブルの名前。

table_owner

削除される前のテーブルのオーナー。

dropby

テーブルを削除したユーザー。

drop_time

テーブルが削除された時刻。

ゴミ箱内のテーブルのストレージ確認

  • 次の構文を使用して、ゴミ箱内のテーブルのストレージを確認できます。table_id パラメーターは必須ではありません。スキーマ名とテーブル名が一意でない場合は、table_id を使用してテーブルを指定できます。

    -- ゴミ箱内のテーブルのストレージサイズを表示します。
    SELECT hologres.hg_recyclebin_relation_size('<schema_name.table_name>'[,<table_id>]);
    
    -- 次の構文を使用して、単位付きの値を返します。
    SELECT PG_SIZE_PRETTY(hologres.hg_recyclebin_relation_size('<schema_name.table_name>'[,<table_id>]));

    構文の使用方法を次の例に示します:

    -- 削除されたテーブルが tbl1 という名前で、public スキーマに属しているとします。
    SELECT hologres.hg_recyclebin_relation_size('public.tbl1');
    
    -- ゴミ箱内に同じスキーマ名とテーブル名を持つ複数のテーブルがある場合は、table_id を使用して特定のテーブルを指定します。例:
    SELECT hologres.hg_recyclebin_relation_size('public.tbl1', 42);
  • 監視メトリクスを使用して、各 DB のテーブルのゴミ箱が占有するストレージを表示できます。

    V3.1.32、V3.2.12、および V4.0.2 以降、Hologres はテーブルのゴミ箱のストレージ監視メトリクスを提供します。これらのメトリクスを使用して、各 DB のゴミ箱のストレージを表示できます。

ゴミ箱の保持期間の設定

デフォルトでは、ゴミ箱内のテーブルは 1 日間保持されます。この期間が過ぎると、システムは自動的にテーブルをパージし、回復できなくなります。必要に応じてゴミ箱を有効または無効にできます。また、次の構文を使用して、必要に応じて保持期間を変更することもできます。

ALTER DATABASE <db_name> SET hg_recyclebin_retention_days = 5; -- テーブルの保持期間を 5 日に変更します。
説明
  • ゴミ箱内のテーブルに対してもストレージ料金が引き続き課金されます。

  • 保持期間は日数で測定されます。最小値は 1、最大値は 10 です。

  • スーパーユーザーのみがこの文を実行できます。この文は DB レベルで有効になります。

ゴミ箱からのテーブルのパージ

PURGE コマンドを使用して、ゴミ箱から手動でテーブルをパージできます。コマンドは次のとおりです:

-- 単一のテーブルをパージします。
purge TABLE {table_name};

-- ゴミ箱からすべてのテーブルをパージします。このコマンドはスーパーユーザーが実行する必要があります。
CALL hologres.hg_purge_all_tables();
説明
  • コマンドが正常に実行されると、テーブルは直ちに削除されます。ゴミ箱で見つけることも、回復することもできません。

  • パージできるのはテーブルのみです。依存する動的テーブルはパージできません。

  • テーブルをパージする権限:PURGE コマンドを実行するには特定の権限が必要です。詳細については、「権限」をご参照ください。

テーブルを削除してゴミ箱をバイパス

デフォルトでは、DROP TABLE または DROP Dynamic Table [CASCADE] コマンドで削除されたテーブルはゴミ箱に移動されます。ゴミ箱をバイパスしてテーブルを完全に削除するには、次のコマンドを使用できます:

DROP TABLE <table_name> [CASCADE] FORCE;

権限

ゴミ箱内のクエリ権限

  • テーブルオーナーは、自分が削除したテーブルのみを表示でき、他のユーザーが削除したテーブルは表示できません。

  • スーパーユーザーは、ゴミ箱内のすべてのテーブルを表示できます。

ゴミ箱内のテーブルの削除、回復、パージの権限

  • テーブルの削除

    スーパーユーザー、開発者または管理者ユーザーグループ (SPM/SLPM) のユーザー、およびテーブルオーナー (標準 PostgreSQL 権限モデル) のみが DROP コマンドを実行してテーブルをゴミ箱に移動できます。

  • テーブルのパージ

    スーパーユーザー、開発者または管理者ユーザーグループ (SPM/SLPM) のユーザー、およびテーブルオーナー (標準 PostgreSQL 権限モデル) のみが PURGE コマンドを実行してゴミ箱からテーブルをパージできます。

  • テーブルの回復

    スーパーユーザー、開発者または管理者ユーザーグループ (SPM/SLPM) のユーザー、テーブルオーナー (標準 PostgreSQL 権限モデル)、およびテーブルを削除したユーザーのみが RECOVER コマンドを実行してテーブルを回復できます。

説明
  • SPM/SLPM 権限モデルでは、テーブルがゴミ箱に移動される前に開発者または管理者ユーザーグループにいたユーザーのみが、ゴミ箱内のそのテーブルを管理できます。テーブルがゴミ箱に移動された後に開発者または管理者ユーザーグループに追加されたユーザーは、そのテーブルを管理できません。

  • SPM/SLPM からエキスパートモードに切り替えると、スーパーユーザーのみがゴミ箱内のテーブルを復元およびパージできます。

特殊な例:

user1 が schema1 のオーナーであり、user2 が schema1.table2 のオーナーである場合、user1 は schema1 と schema1.table2 を削除できます。ただし、user2 が user1 に必要な権限を付与していないため、user1 は schema1.table2 にアクセスできません。

-- 1. user1 が schema1 を作成し、そのスキーマに対する CREATE 権限を user2 に付与します。
CREATE SCHEMA schema1;
GRANT CREATE ON SCHEMA schema1 TO "BASIC$user2";

-- 2. user2 が schema1.table2 を作成し、テーブルオーナーになります。
CREATE TABLE schema1.table2(id INT);

-- user1 は schema1 とそのすべてのオブジェクト (table2 を含む) を削除できますが、table2 を表示することはできません。
SELECT * FROM schema1.table2; 
# ERROR:  permission denied for table table2

DROP SCHEMA schema1 CASCADE; 
# DROP CASCADES TO TABLE schema1.table2
# DROP SCHEMA

table2 を回復するには、2 つのオプションがあります:

  • テーブルを削除した user1 が、schema1 内のテーブルを回復できます。

  • テーブルオーナーである user2 が、テーブルを回復できます。

テーブルを削除してからゴミ箱から回復

例 1: 標準テーブルの削除と回復

  1. 標準テーブルを作成して削除します。

    CREATE TABLE tbl1 (
      id INT NOT NULL)
    WITH (
        orientation = 'column',
        distribution_key = 'id',
        clustering_key = 'id',
        event_time_column = 'id');
    INSERT INTO tbl1 SELECT i  FROM GENERATE_SERIES(1, 1000000) i;
    DROP TABLE tbl1;
  2. ゴミ箱を表示して、テーブルが存在することを確認します。

    SELECT * FROM hologres.hg_recyclebin;

    結果は次のとおりです:

    table_id | schema_name | table_name |   table_owner   |    dropby   |   drop_time        
    ---------+-------------+------------+-----------------+-------------+-----------------------
           14| public      | tbl1       | xx_developer  | 1365xxxxxxxx| 2025-04-17 19:23:10+08
    (1 row)

    テーブルのストレージを表示します:

    SELECT (hologres.hg_recyclebin_relation_size('tbl1')/1024)::text||'KB' AS hg_recyclebin_relation_size;

    ストレージの結果は次のとおりです:

    hg_recyclebin_relation_size 
    -----------------------------
                          1336KB
    (1 row)
  3. テーブルを回復します。

    -- 標準テーブル tbl1 のすべてのデータとプロパティ (PK とクラスタリングキーを含む) を回復します。
    RECOVER TABLE tbl1;  

例 2: パーティションテーブルの削除と回復

  1. 親テーブルと子テーブルを持つパーティションテーブルを作成します。

    CREATE TABLE tbl2_parent(id INT) PARTITION BY list (id);
    CREATE TABLE tbl2_child_1 PARTITION OF tbl2_parent FOR VALUES IN (1);
    CREATE TABLE tbl2_child_2 PARTITION OF tbl2_parent FOR VALUES IN (2);
  2. 子テーブルの 1 つを削除して回復します。回復された子テーブルは標準テーブルになります。元のパーティション親テーブルに手動でアタッチする必要があります。

    -- パーティション子テーブルを削除します。
    DROP TABLE tbl2_child_1;
    
    -- パーティション子テーブルはゴミ箱に移動されます。
    SELECT * FROM hologres.hg_recyclebin;

    結果は次のとおりです:

    table_id | schema_name |  table_name  |   table_owner    |   dropby  |       drop_time        
    ----------+-------------+--------------+------------------+-----------+------------------------
           16 | public      | tbl2_child_1 | xx_developer   | 1365xxxxx | 2025-04-17 19:33:30+08
    (1 row)

    パーティション子テーブルを回復し、その構造を確認します。このテーブルはパーティション子テーブルではなく、標準テーブルになっています。

    RECOVER TABLE tbl2_child_1;  
    SELECT hg_dump_script('tbl2_child_1');

    結果は次のとおりです:

     hg_dump_script                        
    --------------------------------------------------------------
     BEGIN;                                                      +
                                                                 +
     /*                                                          +
     DROP TABLE public.tbl2_child_1;                             +
     */                                                          +                   
     CREATE TABLE public.tbl2_child_1 (                          +
         id INTEGER                                              +
     ) WITH (                                                    +
     orientation = 'column',                                     +
     storage_format = 'orc',                                     +
     table_group = 'xxxx_tg_default',                            +
     table_storage_mode = 'any',                                 +
     time_to_live_in_seconds = '3153600000'                      +
     );                                                          +
                                                                 +
                                                                 +
                                                                 +
     COMMENT ON TABLE public.tbl2_child_1 IS NULL;               +
     ALTER TABLE public.tbl2_child_1 OWNER TO "xx_developer";    +
                                                                 +
                                                                 +
     END;                                                        +
     
    (1 row)
  3. パーティション親テーブルを削除します。回復後、パーティションテーブルとして復元されます。

    -- パーティション親テーブルを削除します。
    DROP TABLE tbl2_parent CASCADE;
    
    -- ゴミ箱を表示します。親テーブルとその子テーブルがゴミ箱に移動されます。
    SELECT * FROM hologres.hg_recyclebin;                   

    結果は次のとおりです:

    table_id | schema_name |  table_name  |   table_owner |      dropby   |       drop_time        
    ---------+-------------+--------------+---------------+---------------+------------------------
          17 | public      | tbl2_child_2 | xx_developer | 1365xxxxxxxx | 2025-04-17 19:41:04+08
          15 | public      | tbl2_parent  | xx_developer | 1365xxxxxxxx | 2025-04-17 19:41:04+08

    パーティション親テーブルを回復できます。

    RECOVER TABLE tbl2_parent; 

    PSQL クライアントで次の文を実行して、パーティション親テーブルの DDL を表示できます。

    \d+ tbl2_parent;

    子テーブルも回復されます。

                              Partitioned table "public.tbl2_parent"
     Column |  Type   | Collation | Nullable | Default | Storage | Stats target | Description
    --------+---------+-----------+----------+---------+---------+--------------+-------------
     id     | integer |           |          |         | plain   |              |
    Partition key: LIST (id)
    Partitions: tbl2_child_2 FOR VALUES IN (2)

例 4: 名前が競合するテーブルの回復

  • テーブルを削除した後に同じ名前の新しいテーブルを作成した場合、削除されたテーブルの回復は失敗します。まず既存のテーブルの名前を変更する必要があります。

    1. tbl6 を作成して削除します。

      CREATE TABLE tbl6(id INT);
      -- テーブルを削除します。テーブルはゴミ箱に移動されます。
      DROP TABLE tbl6;
    2. 同じく tbl6 という名前の新しいテーブルを作成し、削除されたテーブルを回復しようとします。

      CREATE TABLE tbl6(id INT);
      RECOVER TABLE tbl6;   

      同じ名前のテーブルがすでに存在するため、回復は失敗します。既存のテーブルを削除または名前変更する必要があります。

      ERROR:  Table public.tbl6 already exists
    3. 既存のテーブル tbl6 の名前を tbl6_rename に変更し、元の tbl6 を回復します。これで回復は成功します。

      ALTER TABLE tbl6 rename to tbl6_rename;
      RECOVER TABLE tbl6; 
  • 同じ名前の新しいテーブルが、削除されたテーブルと同じ PK とクラスタリングキーを持っている場合、名前を変更しても競合は解決されません。元のテーブルを回復するには、新しいテーブルを別のスキーマに移動するか、削除する必要があります。

    1. テーブル tbl1 を作成し、その後削除を実行します。

      -- テーブルを作成し、PK とクラスタリングキーを設定します。
      CREATE TABLE tbl1 (
          col1 INT,
          col2 INT,
          col3 INT,
          PRIMARY KEY (col1, col2)
      )
      WITH (
          clustering_key = 'col1'
      );
      -- テーブルを削除します。
      DROP TABLE  tbl1;
      
      -- 同じ名前のテーブルを再作成し、PK とクラスタリングキーを設定します。
      CREATE TABLE tbl1 (
          col1 INT,
          col2 INT,
          col3 INT,
          PRIMARY KEY (col1, col2)
      )
      WITH (
          clustering_key = 'col1'
      );
      
      -- ゴミ箱を表示します。
      SELECT * FROM  hologres.hg_recyclebin;

      結果は次のとおりです。

      table_id | schema_name | table_name |   table_owner    |      dropby      |       drop_time        
      ----------+-------------+------------+------------------+------------------+------------------------
             493497 | public      | tbl1         | 13659371xxx| 13659371xxx | 2025-04-17 20:11:08+08
    2. ゴミ箱から直接 tbl1 テーブルを回復しようとすると失敗します。

      -- ゴミ箱から削除されたテーブルを回復します。エラーが報告され、回復は失敗します。
      RECOVER  TABLE tbl1;

      エラーは次のとおりです。

      ERROR: Table public.tbl1 already exists
    3. tbl1 テーブルの名前を変更してから回復しようとしても、やはり失敗します。

      -- 既存のテーブルの名前を変更します。
      ALTER TABLE tbl1 RENAME TO tbl2;
      
      -- 既存のテーブルには PK とクラスタリングキーがあるため、回復は依然として失敗します。
      RECOVER  TABLE tbl1;

      次のエラーメッセージが返されます。

      ERROR: relation "tbl1_pkey" already EXISTS IN SCHEMA "public" 
    4. tbl1 テーブルを別のスキーマに移動してから回復します。これで回復は成功します。

      CREATE SCHEMA test;
      ALTER TABLE tbl2 SET SCHEMA test;
      
      -- 回復は成功します。
      RECOVER  TABLE tbl1;

テーブルを削除してゴミ箱をバイパス

-- 標準テーブルをゴミ箱に移動せずに削除します。
CREATE TABLE tbl1(id INT);
DROP TABLE tbl1 FORCE;   

ゴミ箱からのテーブルのパージ

CREATE TABLE tbl1(id INT);
DROP TABLE tbl1;
-- ゴミ箱からテーブルをパージします。
PURGE TABLE tbl1;