ディスク上のどのファイルがテーブルに対応するかを判断する必要がある場合があります。
base / 16499/19401などの数字で満たされたパスがあり、それを把握したい場合。 ファイル名に言及しているエラーメッセージを見ることができます、例えば：
ERROR: could not read block 11857 of relation base/16396/3720450: read only 0 of 8192 bytes
関係の方法を探す
次を使用して、テーブルへのパスを確認できます。
SELECT pg_relation_filepath('tablename');
しかし、パスからオブジェクトの名前を取得する逆のプロセスはどうですか？
pg_filenode_relationという関数がありますが、これはこれに適しているように思えますが、使用するには、このファイルが属する特定のデータベースに接続する必要があります。
ファイルパス構造
PostgreSQLの最新バージョンでテーブルとデータベースへのパスを決定する方法は次のとおりです。 （古いバージョンは別の形式を使用しており、これについては
こちらで読むことができ
ます ）。
パスには3つの主なオプションがあります。
- デフォルトのテーブルスペース内のファイルの場合、リレーションのbase / database_oid / filenode id
- 他の表スペースのファイルの場合： pg_tblspc / tablespace_oid / tablespace_version_subdir / database_oid / filenode id relationship
- 一般的な関係の場合： グローバル/ファイルノードIDの関係
一般的な関係については最後に説明します。 最も頻繁に出会う最も一般的な最初の2つのオプションについては、パスの最後の部分は同一で、OIDベースとOIDの関係です。
「
oid relationship 」ではなく、「
filenode id of relationship 」という表現を使用したことに注意してください。 これは、PostgreSQLが
pg_relfilenode.mapと呼ばれるファイルに各データベース/テーブルスペースの
relfilenodeマップを持って
いるためです。 テーブルファイル名は必ずしも
pg_classの OIDと一致するわけではなく、
VACUUM FULL、TRUNCATEなどの実行後に変更できます。 例：
test=> select pg_relation_filepath('a'); pg_relation_filepath
だから。 このパスを関係名に戻す方法は？
データベースOIDとファイルノードIDの関係
この記事の最初からエラーが発生したとします。 それはいくつかの部分に分けることができます：
- base：デフォルトのテーブルスペース内
- 16396：OID 16396のデータベース内
- OID 3720450を持つテーブルの3720450ファイルノードID
次に、それぞれの意味を検討します。
OIDデータベース定義
まず、このPostgreSQlプロセスのデータベースに接続して実行する必要があります。
select datname from pg_database where oid = 16396
（またはあなたが持っている他のoidベース）。 これにより、データベース名が返されます。
その後、このデータベースに接続する必要があります。
relfilenodesをバージョン9.4に逆変換
バージョン9.4以降を使用している場合、次の部分は簡単です。
SELECT pg_filenode_relation(0, 3720450);
（0は「デフォルトのテーブルスペース」を意味します）
この関数は、relfilenodeの逆変換を実行します。 そうすれば、テーブルの名前が表示されるだけです。 受信したテーブル名が現在の
search_pathに属している場合、何らかのスキームとの接続は表示されません。
SET search_path = '';を使用できます
。 関数を実行する前に、回路へのパスが示されるようにします。
正しいデータベースに接続する必要があります。そうしないと、間違った回答が受信されるか、回答がまったく受信されません。
バージョン9.3でのRelfilenodesの逆変換
バージョン9.3以前を使用している場合、テーブルが置かれているデータベースに接続し、
pg_classに対して次のクエリを実行する必要があります。
select n.nspname AS tableschema, c.relname AS tablename from pg_class c inner join pg_namespace n on (c.relnamespace = n.oid) where c.relfilenode = 3720450;
（またはテーブルのその他の受信したrelfilenode id）。
これにより、このエラーがどのテーブルに属しているかがわかります。
結果なし？
まあ、それは通常役立ちます。
Relfilenodeをnullにすることもできます。これは、ファイルが
pg_relfilenode.mapを介して配置されることを意味します。 これは、一般的なシステムディレクトリ、それらのインデックス、TOASTテーブルなどの典型的なシナリオです。 たとえば、
pg_database 、
pg_class 、および
pg_procです。
サーキットはどうですか？
スキーマ（名前空間）がパスに表示されないことに気付きましたか？
PostgreSQLでは、スキーマはデータベース内の名前空間にすぎません。 テーブルが物理的にディスクのどこに保存されるかには影響しません。
他の表領域パス
私が遭遇した最近のケースは次のエラーでした：
ERROR: could not truncate file "pg_tblspc / 16709 / PG_9.3_201306121 / 16499/19401" to 8 blocks: Permission denied
パスはpg_tblspcで始まるため、これはデフォルトのテーブルスペースではありません。
テーブルを見つけるプロセスは実際には同じです。
pg_tblspc / nnn / PG_n.n_nnnnnn / partを無視して、上記のデフォルトの表スペースの場合で説明したように、すぐに
database_oid / relation_oidに集中できます。 これを行うには、パスの意味を理解します。
したがって、エラーテキストは次の部分に分割されます。
- pg_tblspc：これはデフォルトのテーブルスペースではありません
- 16709：これはOID 16709の表領域です
- PG_9.3_201306121：カタログバージョン201306121のPostgreSQL 9.3で使用されます。
- 16499：OID 16499のデータベース
- relfilenode id 19401の19401テーブル
データベースoidとテーブルベースのrelfilenode idについてはすでに説明しました。 表スペースと違いはありません。他の場所でのみ開始されます。
では、表領域の部分はどうでしょうか？
pg_tblspcはPostgreSQLデータディレクトリ内のディレクトリで、テーブルスペース（またはNTFS、それらの接続ポイント）のすべての位置への
シンボリックリンクが含まれてい
ます 。 各シンボリックリンクの名前は、oidテーブルスペースに基づいています。 これは、PostgreSQLがテーブルスペースを見つける方法です。 表スペースに対するSQLコマンドは、これらのリンクで動作します。
OIDは、
以下からわかるように、表スペースの
pg_tablespaceエントリーを指します。
select spcname from pg_tablespace where oid = 16709;
テーブルスペースディレクトリ内には、PostgreSQLのバージョンに対応する名前を持つ別のディレクトリがあります。 このバージョンでは静的であり、唯一のアプリケーションは、たとえばpg_upgrade中など、同じテーブルスペースへの複数のPostgreSQLプロセスの複数アクセスです。 通常、エントリは1つだけです。
一般に、構造はベース/パスと同じです-最初にOIDデータベース、次にOID関係。
グローバル（一般）テーブル
エラーの3番目のカテゴリがあります。それを観察した場合、間違いなく問題が発生しています。 PostgreSQLには共通のディレクトリがあります-各データベースで同じコンテンツを持つテーブル。 それらは、relfilenode id 16709の特別なテーブルスペースにあります。
それらへのパスは
ベースではなく
グローバルで始まり、データベースoidを持つコンポーネントはありません。
共有ディレクトリは
pg_classの relfilenodeでマークされていません。 つまり、たとえば
pg_classの pg_databaseを見ることができません。
pg_filenode_relationは、デフォルトのテーブルスペースoidで呼び出すか、1664グローバルテーブルスペースoidで呼び出すかに関係なく、nullを返します。
これを明確にすることは、解析されたリンクを含む後続の記事のトピックです。
もちろん、共有ディレクトリで問題が発生している場合、原則としてデータベースを起動することはできません。
ダメージに対処する
データベースの破損は発生しません。 しかし、それはとにかく起こります。 ハードウェア、カーネルバグ、またはファイルシステムの問題、信頼できるディスクの潮流、バグのあるストレージネットワーク、そしてもちろんPostgreSQLのバグをコミットすることについて嘘をつくSSDです。 データベースの損傷が疑われる場合は、何かを行う前に、
Wikiページの破損に関するアドバイスを読んでそれに従って
ください 。
内部
すべての動作を確認するには、src / include / common / relpath.hでrelpathbackendマクロを実行します。 src / common / relpath.cのGetRelationPathを呼び出します。
このマニュアルでは、ディスク上のデータベース構造を考慮しています。
リンク