Posts

冒頭まとめ AWSへのリクエストで次のエラーが出る場合、送信した署名とAWS側が同じリクエストから再計算した署名が一致していません。 SignatureDoesNotMatch The request signature we calculated does not match the signature you provided. Check your key and signing method. 最初に、AWS SDKまたはAWS CLIでも同じ操作が失敗するか確認します。SDKやCLIでは成功するなら、資格情報そのものより、独自に実装した署名処理、リクエストの変更、事前署名URLの使い方に原因がある可能性が高くなります。 AWS CLIでも失敗する場合は、使用中のアクセスキー、プロファイル、リージョン、時刻を確認してください。S3の事前署名URLでは、URL、HTTPメソッド、Content-Typeなどの署名対象が発行時と使用時で一致している必要があります。 SignatureDoesNotMatchの意味 AWS Signature Version 4は、HTTPメソッド、パス、クエリ文字列、見出し、本文の要約値などから署名を作る認証方式です。AWSは署名付きリクエストを受け取ると、受信した内容から署名を再計算して、送られた署名と比較します。 一致しなければ、HTTP 403とSignatureDoesNotMatchが返ります。AWS公式のSigV4トラブルシューティングにも、署名値がAWS側の計算結果と一致しないエラーだと記載されています。 HTTP 403だけを見て、すべてIAM権限の問題と判断してはいけません。Amazon S3では、権限拒否のAccessDeniedも403ですが、SignatureDoesNotMatchは署名不一致を示します。エラーの状態コードだけでなく、コードと本文を確認してください。 IAMポリシーを広げても、誤った署名は正しくなりません。まず署名と資格情報を直し、その後にAccessDeniedが出た場合は必要な権限を調べます。 SDKやCLIでも失敗する場合 AWS CLIがどのプロファイル、アクセスキー、リージョンを使っているか確認します。 aws configure list このコマンドはアクセスキーとシークレットアクセスキーの一部を伏せ、値の取得元も表示します。環境変数、共有資格情報ファイル、指定したプロファイルのどれが使われているかを確認してください。 名前付きプロファイルを使う場合は、対象を明示します。 aws configure list --profile example 資格情報でAWS APIを呼べるかは、次のコマンドでも確認できます。 aws sts get-caller-identity --profile example 想定と違う利用者やロールが表示された場合は、環境変数、プロファイル、実行環境に割り当てたロールを見直します。アクセスキーIDとシークレットアクセスキーが別の組から混ざっていないかも確認してください。 一時的な資格情報を使う場合は、アクセスキーとシークレットアクセスキーに加えてセッショントークンが必要です。AWS公式の署名手順では、X-Amz-Security-Tokenを見出しまたはクエリ文字列へ含めるよう説明されています。 計算機の時刻も確認します。 date -u Windows PowerShellでは次を実行できます。 Get-Date -AsUTC 時刻がずれている場合は、OSの自動時刻設定や時刻同期を有効にします。仮想マシンや休止状態から復帰した環境では、ホストとの時刻同期も確認してください。 手動署名ではCanonical Requestを比較する SDKやCLIを使わずに署名を組み立てている場合は、Canonical RequestとString to Signを確認します。Canonical Requestは、リクエストを署名計算用の決められた形へ並べ直した文字列です。 SigV4のCanonical Requestは、次の要素を改行で連結します。 ...

冒頭まとめ npm installやnpm publishで次のエラーが出る場合、パッケージの取得先から認証を拒否されています。 npm error code E401 npm error Unable to authenticate, your authentication token seems to be invalid. 最初に、失敗したURLと使用中のレジストリを確認してください。次に、.npmrcの認証情報がそのレジストリに結び付いているか、CIへNPM_TOKENなどの環境変数が渡されているかを調べます。 GitHubの公式発表によると、2025年12月9日にnpmのclassicトークンがすべて無効化されました。古いトークンをCIや.npmrcに残している場合は、現在有効なgranular access tokenへの交換が必要です。 npm E401の意味 E401は、接続したレジストリが認証情報を受け付けなかったときに表示されます。レジストリとは、npmパッケージを取得または公開するサーバーです。 表示は1種類ではありません。代表的には、トークンが無効であるという案内、パスワードが未設定または誤っているという案内、二段階認証を求める案内があります。社内レジストリなどでは、レジストリ側が返した独自の文が表示される場合もあります。 重要なのは、E401が必ずnpmjs.comから返るとは限らないことです。@myorg/packageのようにscopeが付いたパッケージは、設定によってGitHub Packagesや社内レジストリへ送られます。エラーに含まれるURLを基準に調べてください。 使用中のレジストリを確認する 既定のレジストリは次のコマンドで確認できます。 npm config get registry scope付きパッケージで失敗した場合は、そのscopeに別のレジストリが設定されていないか確認します。 npm config get @myorg:registry たとえば、次の設定があると、@myorgで始まるパッケージのインストールと公開はGitHub Packagesへ送られます。 @myorg:registry=https://npm.pkg.github.com npm公式のscope文書では、scopeをレジストリへ関連付けると、そのscopeのパッケージは指定先から取得され、同じ指定先へ公開されると説明されています。 エラーのURLがregistry.npmjs.orgではなく、npm.pkg.github.comや社内のホスト名なら、その取得先用の認証情報を確認します。 トークンが期限切れまたは無効になっている 昨日まで動いていたCIが突然E401になった場合は、トークンの期限切れや無効化を確認します。 npmでは2025年12月9日にclassicトークンが恒久的に無効化されました。現在はgranular access tokenだけがサポートされています。また、2025年9月の公式発表では、書き込み権限を持つgranular access tokenの有効期限は上限90日とされています。 CIの秘密情報にclassicトークンや期限切れトークンが残っている場合は、npm上で用途と権限を絞った新しいgranular access tokenを作成し、CI側の秘密情報を交換します。トークンの値は.npmrcやワークフローへ直接書かず、CIの秘密情報として保存してください。 ローカル環境からnpmjs.comへ公開する場合は、次のコマンドでログインし直せます。 npm login 2025年12月9日以降、npm loginで作られるのは2時間で期限切れになるセッショントークンです。これはローカルでの公開操作を続けるための短時間の認証であり、CIへ長期保存するトークンには適しません。CIでの公開にはgranular access tokenを使うか、対応環境ではOIDCによるtrusted publishingを検討します。 CIに環境変数が渡されているか確認する .npmrcでは、環境変数を次のように参照できます。 //registry.npmjs.org/:_authToken=${NPM_TOKEN} npm公式の.npmrc文書によると、NPM_TOKENが未定義の場合、${NPM_TOKEN}は空文字へ自動変換されず、そのまま残ります。結果として、正しいトークンではない値で認証を試み、E401になる可能性があります。 値そのものを表示せず、環境変数が設定されているかだけを確認してください。macOSやLinuxのシェルでは次を使えます。 test -n "$NPM_TOKEN" && echo "NPM_TOKEN is set" || echo "NPM_TOKEN is empty" PowerShellでは次のように確認します。 ...

冒頭まとめ npm installなどで次のエラーが出る場合、npmがHTTPS通信で検証した証明書の有効期限が切れています。 npm error code CERT_HAS_EXPIRED npm error errno CERT_HAS_EXPIRED 最初に接続先URLとnpmレジストリを確認してください。公式レジストリではなく、社内レジストリ、ミラー、プロキシを経由している場合は、その途中で提示された証明書が原因になることもあります。 次にnpmのcaとcafile、Node.jsのバージョンを確認します。古いCA証明書が明示的に設定されている場合は設定を更新し、Node.jsが古い場合はサポート中の版へ更新します。証明書の検証を無効にするstrict-ssl=falseは、安全な解決方法ではありません。 CERT_HAS_EXPIREDの意味 CERT_HAS_EXPIREDは、Node.jsのTLS処理が返すX.509証明書エラーです。Node.js公式文書では「証明書の有効期限が切れている」状態として定義されています。 npmはパッケージやメタデータをHTTPSで取得するとき、接続先から提示された証明書をNode.jsで検証します。証明書チェーンの検証対象に期限切れの証明書が含まれていると、npmは通信を中止し、このコードを表示します。 エラーはパッケージの依存関係やpackage-lock.jsonの内容そのものを示すものではありません。DNS解決とTCP接続の後に行われるTLS証明書の検証で失敗しています。Node.js公式のTLSエラーコード一覧で定義を確認できます。 最初に接続先と設定を確認する エラーの前後に表示されたURLを確認します。npmが使用する既定レジストリも調べてください。 npm config get registry https://registry.npmjs.org/以外が表示された場合は、社内レジストリやミラーの証明書を確認します。ただし、レジストリが公式URLでも、HTTPSプロキシが通信を中継していれば、実際に検証している証明書はプロキシが発行したものかもしれません。 続いて、Node.jsのバージョンとnpmの証明書設定を確認します。 node -v npm config get ca npm config get cafile npm config get strict-ssl caまたはcafileに値がある場合は、その設定が意図したものか、参照先の証明書が現在も有効かを確認します。strict-sslの既定値はtrueです。 環境変数も確認します。macOSやLinuxでは次を実行します。 printf '%s\n' "$NODE_EXTRA_CA_CERTS" PowerShellでは次のように確認できます。 $env:NODE_EXTRA_CA_CERTS 接続先やプロキシの証明書が期限切れの場合 社内レジストリ、キャッシュ用ミラー、HTTPSプロキシなどの証明書が期限切れなら、サーバーまたはプロキシ側で証明書を更新する必要があります。利用者側でnpmの検証を無効にしても、期限切れそのものは解消しません。 OpenSSLを利用できる環境では、実際の接続先ホストを指定して証明書の有効期間を確認できます。 openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates notAfterが有効期限です。ただし、プロキシを経由する環境でこのコマンドがnpmと同じ通信経路を通るとは限りません。ブラウザ、プロキシ管理画面、組織の証明書管理手段も併用し、npmが実際に受け取った証明書を確認してください。 公開レジストリ側の障害が疑われる場合は、npmのサービス稼働状況も確認します。社内レジストリやプロキシの場合は、管理者へ接続先URL、発生時刻、証明書の発行者と有効期限を伝えると調査しやすくなります。 npmのcaまたはcafileが古い場合 npmのcaは、レジストリとのSSL接続で信頼するCA証明書を直接指定する設定です。cafileは、1つ以上のCA証明書を含むファイルのパスを指定します。どちらも既定値はnullです。npm公式のconfig文書に仕様があります。 過去に社内CAや古い証明書を登録し、その設定だけが残っていると、現在の正しい証明書チェーンを検証できないことがあります。設定が不要になったことを確認できた場合は削除します。 npm config delete ca npm config delete cafile 削除後に値を確認し、もう一度インストールします。 ...

冒頭まとめ PostgreSQLへの接続時に次のエラーが出る場合、pg_hba.confに接続条件と一致する規則がありません。 FATAL: no pg_hba.conf entry for host "192.168.1.10", user "app", database "mydb", no encryption エラーに表示された接続元IP、利用者名、データベース名、暗号化状態を確認し、この4つに合う規則を探してください。規則を追加する場合は、接続元を必要な範囲に絞り、scram-sha-256など適切な認証方式を指定します。 Linuxなどでは、ファイルの保存後に設定の再読み込みが必要です。Microsoft Windowsでは、変更内容がその後の新しい接続へ直ちに適用されます。 no pg_hba.conf entry for hostの意味 pg_hba.confは、PostgreSQLへ接続できる利用者、データベース、接続元、認証方式を定めるファイルです。HBAはhost-based authenticationの略で、接続元に基づく認証設定を指します。 PostgreSQLは、接続種別、接続元アドレス、要求されたデータベース、利用者名の4つを上から順に照合します。一致する規則が1つもなければ、接続を拒否してno pg_hba.conf entry for hostを返します。 このエラーのSQLSTATEは28000、条件名はinvalid_authorization_specificationです。パスワードが違う場合の28P01とは別のエラーです。PostgreSQL公式のエラーコード一覧で確認できます。 エラー文の4項目を確認する エラー文には、原因を絞るための情報が含まれています。 host "192.168.1.10" user "app" database "mydb" no encryption hostの値は、PostgreSQLから見た接続元IPです。利用者が想定していたIPではなく、エラーに表示された値を基準にしてください。 userとdatabaseは、接続時に指定されたPostgreSQLの利用者名とデータベース名です。似た名前の別環境へ接続していないかも確認します。 末尾のno encryptionは暗号化されていない接続です。環境によってはSSL encryptionまたはGSS encryptionと表示されます。これは単なる補足ではなく、hostsslなどの接続種別と照合する条件です。 pg_hba.confの場所を確認する 編集すべきファイルの場所は、接続済みの管理用セッションから確認できます。 SHOW hba_file; PostgreSQLは認証設定ファイルを別の場所へ移せるため、想像した場所のファイルを編集すると反映されないことがあります。必ず実際に使用されているパスを確認してください。 接続できる管理用セッションがない場合は、サーバーの設定管理、コンテナのマウント設定、クラウドサービスの管理画面などで使用中の認証設定を確認します。管理サービスではpg_hba.confを直接編集できない場合があります。 読み込める規則と書式エラーを調べる pg_hba_file_rulesを使うと、pg_hba.confの規則と書式エラーを確認できます。既定ではスーパーユーザーだけが参照できます。 SELECT rule_number, file_name, line_number, type, database, user_name, address, auth_method, error FROM pg_hba_file_rules ORDER BY file_name, line_number; errorがNULLではない行には、読み取れない理由が入ります。誤った行では、line_numberとerror以外が空になることがあります。 ...

冒頭まとめ PostgreSQLへの接続時に次のエラーが出る場合、利用できる接続枠がすべて使われています。 FATAL: sorry, too many clients already まず、接続済みの管理用セッションがあればpg_stat_activityで内訳を確認します。不要な接続を安全に終了し、アプリケーションが接続を閉じているか、複数の接続プールの上限が大きすぎないかを調べてください。 max_connectionsを上げるだけでは、接続の増え続ける原因は解消しません。この設定の変更にはPostgreSQLの再起動が必要で、値を増やすと共有メモリを含む資源の割り当ても増えます。先に接続の使い方を直し、それでも必要な場合に限って上限を見直します。 sorry, too many clients alreadyの意味 PostgreSQLは、同時に受け付ける接続数をmax_connectionsで制限しています。利用可能な接続枠を使い切ると、新しい接続を受け付けられず、sorry, too many clients alreadyを返します。 このエラーのSQLSTATEは53300、条件名はtoo_many_connectionsです。アプリケーションでエラーを判定するときは、表示文ではなくSQLSTATEを使うと、言語設定や文言の違いに影響されにくくなります。PostgreSQL公式のエラーコード一覧でも確認できます。 PostgreSQL本体では、接続処理に必要な領域を確保できなかったときに、このエラーを返します。処理はPostgreSQL本体のproc.cで確認できます。 似た2つのエラーとの違い 接続枠が少なくなった段階では、別の文言が表示されることがあります。 FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute この場合は接続枠が完全になくなったわけではなく、残りがスーパーユーザー用に確保されています。スーパーユーザーで管理用接続を確立し、接続状況を調査できる可能性があります。 環境によっては、次の文言が表示されます。 FATAL: remaining connection slots are reserved for roles with privileges of the "pg_use_reserved_connections" role これは、残りがpg_use_reserved_connectionsの権限を持つ役割とスーパーユーザー向けに確保されている状態です。 一方、sorry, too many clients alreadyまで進むと、接続処理に使える枠自体が残っていません。予約された権限を持つ利用者でも、新しい接続に失敗する可能性があります。予約枠の判定と文言はPostgreSQL本体のpostinit.cで確認できます。 接続数と設定値を確認する まだ利用できる管理用接続や既存の管理画面がある場合は、最初に現在値を確認します。 SHOW max_connections; SHOW superuser_reserved_connections; reserved_connectionsに対応する環境では、次の値も確認してください。未対応の版では設定項目が存在しないため、エラーになります。 SHOW reserved_connections; 現在のクライアント接続数は、次のSQLで確認できます。 SELECT count(*) AS client_connections FROM pg_stat_activity WHERE backend_type = 'client backend'; pg_stat_activityにはサーバープロセスごとの状態が表示されます。PostgreSQL公式文書にも、現在の状態や問い合わせを確認する統計ビューとして説明されています。pg_stat_activityの公式資料 ...

冒頭まとめ fatal: detected dubious ownership in repository atは、Gitがリポジトリの所有者を確認し、現在Gitを実行している利用者と一致しないと判断したときに発生します。これはファイルを読み書きできないという意味ではなく、所有者の異なるリポジトリを信頼しないための安全機能です。 自分だけが使うフォルダなら、まず所有者を確認し、誤って別の利用者や管理者の所有になっている場合は所有者を直します。共有リポジトリやコンテナのように、所有者が異なる状態を意図している場合は、信頼できるパスだけをsafe.directoryへ登録してください。 git config --global --add safe.directory "<repository-path>" この設定は原因となった所有者の違いを解消するものではありません。指定したリポジトリを例外として信頼する設定です。内容を確認していないリポジトリや、外部から書き換えられるフォルダは登録しないでください。 エラーの概要 表示されるエラーは次の形式です。 fatal: detected dubious ownership in repository at '<path>' To add an exception for this directory, call: git config --global --add safe.directory <path> Gitは通常、Gitを実行している利用者が所有するリポジトリだけを信頼します。所有者が異なる場合、リポジトリ内の設定やフックを読み込む前に処理を止めます。Gitの公式文書では、所有者が異なっていても信頼するディレクトリをsafe.directoryで個別に登録できると説明されています。 このエラーはWindowsだけでなく、Linux、macOS、Dockerなどのコンテナ、CIでも発生します。特に、ファイルを作成した利用者とGitを実行する利用者が異なる環境で起こりやすくなります。 まず所有者と設定を確認する 先にsafe.directoryを追加するのではなく、誰がリポジトリを所有しているかを確認します。 LinuxやmacOSでは、次のコマンドでフォルダの所有者IDと現在の利用者IDを比較できます。 ls -ldn "<repository-path>" id -u WindowsのPowerShellでは、次のコマンドでフォルダの所有者と現在の利用者を確認できます。 (Get-Acl "C:\path\to\repository").Owner whoami /user すでに登録されているsafe.directoryと、その設定が書かれている場所は次のコマンドで確認できます。 git config --show-origin --get-all safe.directory 何も表示されない場合は、safe.directoryが登録されていません。 信頼できるリポジトリだけを登録する 共有フォルダやコンテナのマウント先など、所有者が異なる状態を意図している場合は、対象のリポジトリを個別に登録します。エラーメッセージに表示されたパスを確認し、絶対パスで指定してください。 git config --global --add safe.directory "<repository-path>" Windowsでは、次のようにスラッシュを使ったパスも指定できます。 git config --global --add safe.directory "C:/work/example" 設定を残さず、そのコマンドだけ実行したい場合は-cを使います。 ...

冒頭まとめ PostgreSQLで次のエラーが出た場合、複数のトランザクションが互いのロック解放を待っています。 ERROR: deadlock detected DETAIL: Process 1234 waits for ShareLock on transaction 5678; blocked by process 4321. Process 4321 waits for ShareLock on transaction 5679; blocked by process 1234. HINT: See server log for query details. 最も重要な対策は、複数の行や表を更新する順序をすべての処理で統一することです。そのうえで、SQLSTATE 40P01を検出したらトランザクション全体を再試行します。 deadlock_timeoutを長くしたり短くしたりしても、デッドロックの原因そのものはなくなりません。まずサーバーログで衝突した問い合わせを特定し、ロックを取る順序を直してください。 deadlock detectedとは デッドロックは、2つ以上のトランザクションが互いに必要なロックを持ち、どちらも先へ進めなくなった状態です。 たとえば、トランザクションAが行1を更新してから行2を待ち、トランザクションBが行2を更新してから行1を待つと、待ち合わせの輪ができます。PostgreSQLはこの状態を自動で検出し、関係するトランザクションの1つを中断して処理を進めます。 どのトランザクションが中断されるかは予測しにくく、アプリケーション側で決めつけてはいけません。明示的にLOCK TABLEを使っていなくても、通常のUPDATEが取得する行ロックだけで発生します。これらの動作はPostgreSQL公式文書のDeadlocksで説明されています。 このエラーのSQLSTATEは40P01、条件名はdeadlock_detectedです。アプリケーションでは文章ではなくSQLSTATEで判定すると、表示言語や文言の変化に影響されにくくなります。PostgreSQLのエラーコード一覧でも40P01を確認できます。 最初にサーバーログを確認する 手元のエラーに表示されるDETAILには、待っているプロセス番号、ロックの種類、トランザクション番号などが並びます。ただし、衝突した問い合わせ文がクライアント側の出力に含まれない場合があります。 HINT: See server log for query details.と表示されたら、PostgreSQLのサーバーログを確認してください。PostgreSQL本体は、クライアント向けの詳細とログ向けの詳細を分けて組み立て、ログ側には各プロセスの問い合わせ文を追加します。この処理はPostgreSQL本体のdeadlock.cで確認できます。 ログには次のような情報が記録されます。 Process 1234: UPDATE accounts SET balance = balance - 100 WHERE acctnum = 22222; Process 4321: UPDATE accounts SET balance = balance + 100 WHERE acctnum = 11111; プロセス番号だけを見て原因を決めず、各問い合わせがどの順序で行や表を操作しているかを比べます。 ...

結論 gyp ERR! build error の build は、原因の名前ではありません。失敗したコマンドの名前です。node-gyp の実装は、処理が例外で終わったときに「そのコマンド名」と error をつないだ見出しを出します。だから configure error や install error も同じ書式で現れます。build と出ていれば、設定の段階は通っていて、組み立ての段階で落ちたという意味になります。 もう1つ押さえる点があります。この段階で node-gyp 自身が投げるエラーは、ほぼ1種類しかありません。実装では、呼び出した make か msbuild が 0 以外で終わったときに、終了コードをそのまま載せたエラーを作ります。つまり gyp ERR! stack の行は「外部のプロセスが失敗した」としか言っていません。 本当の原因は、その上にあります。組み立ての出力は node-gyp を素通りして画面に出るため、gyp ERR! の並びより前に、実際の失敗が文字として残っています。読む場所はそこです。 最初に確認すること gyp ERR! stack の1行目を見ます。 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 この形であれば、組み立てそのものが失敗しています。画面をさかのぼり、error: で始まる最初の行を探してください。複数並んでいても、最初の1件が起点です。 一方、1行目が次のような文であれば、失敗したのは組み立てではなく準備です。 gyp ERR! stack Error: Could not find *.sln file or Makefile. Did you run "configure"? gyp ERR! の末尾に並ぶ System、command、cwd、node -v、node-gyp -v の5行は、失敗のたびに必ず出る環境の記録です。原因は入っていません。ただし node -v の値は、次の原因1の判断に使います。 ...

冒頭まとめ error: failed to push some refs to '...' は、理由を含んでいません。git の実装では、送信の処理が失敗して戻ってきたときに、この1行を無条件で出します。中身が何であれ表示されるため、この行を検索しても自分の状況に合う答えには辿り着きにくくなります。 理由は、この行の1つ上に出ます。! [rejected] で始まる行の末尾、括弧の中に入る語がそれです。入りうる語は non-fast-forward、fetch first、already exists、needs force、stale info の5つと、受け取り側が断ったことを示す [remote rejected] です。 その下に続く hint: の行にも注意が要ります。git は拒否の理由を集めたうえで、if と else if の並びで最初に当てはまった1件だけを表示します。つまり2つのブランチが別々の理由で拒まれても、助言は片方の分しか出ません。助言のとおりに git pull をしても、もう一方は直りません。 助言が1行も出ない場合もあります。stale info と [remote rejected] は、どちらも助言の対象から外れているためです。何も出ないから情報が無いのではなく、そこが読むべき箇所だと考えてください。 エラーの概要 出力は次の形になります。 To https://github.com/OWNER/REPO.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/OWNER/REPO.git' hint: Updates were rejected because the remote contains work that you do not hint: have locally. This is usually caused by another repository pushing to hint: the same ref. If you want to integrate the remote changes, use hint: 'git pull' before pushing again. 読む順序は下からではありません。! で始まる行が先で、error: の行は結果の要約です。送ろうとしたブランチが複数あれば、! の行も複数並びます。 ...

結論 relation "users" does not exist は、対象がこの世に無いという意味ではありません。指定した名前を、今の接続から解決できなかったという意味です。SQL の状態コードは 42P01、名称は undefined_table です。 relation はテーブルだけを指しません。公式ドキュメントは、pg_class がインデックス、シーケンス、ビュー、実体化ビューなども扱い、これらをまとめて relation と呼ぶと説明しています。 読み分けの起点は、文言の中に点があるかどうかです。スキーマ名を自分で書いた場合は relation "public.users" does not exist と点付きになり、書かなかった場合は relation "users" does not exist と名前だけになります。前者は指定したスキーマの中で見つからず、後者は検索経路をたどって見つからなかったという意味です。 そして、この文言は「無い」と「見えない」を区別しません。権限が足りずに検索経路から外れたスキーマも、存在しないスキーマも同じ結果です。 最初に確認すること 今の接続がどこを見ているかを確認します。 SELECT current_database(), current_user; SHOW search_path; 初期状態の検索経路は "$user", public です。先頭は利用者名と同じスキーマを指します。 次に、対象の所在を調べます。 SELECT n.nspname, c.relname, c.relkind FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = 'users'; 行が返らなければ、このデータベースには登録されていません。返るのに参照できないなら、スキーマか綴りの問題です。 原因別の確認方法と解決策 原因1：対象が検索経路に入っていないスキーマにある 上の照会で nspname が public 以外になっている場合です。修飾しない参照は検索経路を順にたどり、最初に一致したものを使います。経路に入っていないスキーマの中身は参照できません。 対処は、呼び出し側で修飾するか経路へ加えるかです。 SELECT * FROM app.users; SET search_path TO app, public; SET はそのセッションの間だけ有効です。毎回同じ状態にしたい場合は、ロールやデータベースへ既定値を設定します。 原因2：スキーマへの USAGE 権限が無い 同じクエリが、利用者を変えると成功する場合です。公式ドキュメントは、自分が所有していないスキーマの中身へ既定では触れられず、所有者が USAGE 権限を与える必要があると説明しています。 ...