web-dev-qa-db-ja.com

おそらく自動分析中に、postgresログに「テキスト検索ディクショナリ "unaccent"が存在しません」エントリ

Postgres 10にアップグレードして以来、postgresqlのメインログにそのようなエントリがたくさんあります。

2018-03-28 08:51:00.281 CEST [97547] ERROR:  text search dictionary "unaccent" does not exist
2018-03-28 08:51:00.281 CEST [97547] CONTEXT:  automatic analyze of table "dbname.public.periodical"

私はすべてのテーブルの多くのインデックスでアクセントなしを使用しています（アクセントなしを不変にすることで（推奨される方法ではないことはわかっていますが、これは歴史的にそうです））。

手動でvacuumdb dbname --table periodicalまたはVACUUM periodicalまたはVACUUM ANALYZE periodical、それはそのようなエラーを生成しません（コマンドラインでもログでも）。

誰かがこれらのメッセージをどのようにして止めることができ、彼らの本当の原因が何であるかもしれないかのヒントを持っていますか？

PostgreSQLバージョン：10.3（Debian 10.3-1.pgdg80 + 1）

postgresqlpostgresql-10autovacuumunaccent
2
P.Péter

インデックスで使用するためにunaccent()のfake -IMMUTABLE関数ラッパーを使用していることは明らかです。暗黙的または明示的に検索辞書「unaccent」に基づいています。使用する辞書は、unaccent()へのオプションの最初の関数パラメーターとして提供できます。辞書の名前はスキーマで修飾できます。それ以外の場合は、現在の _search_path_ のスキーマの1つに存在する必要があります。

拡張機能によって提供される関数unaccent()を操作することはお勧めしません。代わりに、ここで説明するようなラッパー関数を作成して使用します。

あなたの場合、これらのエラーを報告するセッションの_search_path_にないスキーマに追加モジュールunaccentがインストールされている可能性があります。手動で試行すると、同じスキーマが_search_path_includesされているセッションでそれを実行するため、エラーは発生しません。

_search_path_を設定して、すべてのセッションに拡張のスキーマを含めるか、unaccent()の関数呼び出しで辞書をスキーマ修飾することができます。

クライアントプログラムのセキュリティは、Postgres 10.3/9.6.8などで強化されています。これで、が必要です上記のリンクされた回答で示されているように、任意のインデックスで使用された場合のスキーマ修飾関数と辞書。

Postgres 10.3のリリースノート ：

また、以下の2番目の変更履歴エントリで説明されている変更により、インデックス式またはマテリアライズドビューで使用される関数が自動分析中に失敗する、またはダンプ。アップグレード後、そのような問題がないかサーバーログを監視し、影響を受ける機能を修正します。

...

  • Pg_dumpや他のクライアントプログラムで安全でないsearch_path設定を使用しないようにしました（Noah Misch、Tom Lane）

    pg_dump、pg_upgrade、vacuumdb、およびその他のPostgreSQL提供のアプリケーション自体も、前の変更ログエントリで説明されているタイプのハイジャックに対して脆弱でした。これらのアプリケーションは通常スーパーユーザーによって実行されるため、特に魅力的なターゲットを提示します。インストール全体が保護されているかどうかに関係なくそれらを保護するには、それらを変更してpg_catalogスキーマのみをsearch_path設定に含めます。自動バキュームワーカープロセスも同じように動作します。

    ユーザー提供の関数がこれらのプログラムによって間接的に実行される場合（たとえば、インデックス式のユーザー提供の関数）、search_pathがよりタイトになるとエラーが発生する可能性があります。調整して修正する必要があります。それらが呼び出される検索パスについて何も想定しないようにユーザーが提供する関数。これは常に良い習慣でしたが、今は正しい動作に必要です。

太字は私のものを強調しています。

auto-analyzeおよびautovacuumの特別な言及を参照してください？修正するには、インデックスで使用されるラッパー関数のunaccent()呼び出しのスキーマ修飾関数名と辞書を リンクされた回答で示される として使用します。お気に入り：

_CREATE OR REPLACE FUNCTION f_unaccent(text)
  RETURNS text AS
$func$
SELECT public.unaccent('public.unaccent', $1)  -- schema-qualify function and dictionary
$func$  LANGUAGE sql IMMUTABLE;
_

既存の関数定義に基づいて既存のインデックスを再構築せずに、_CREATE OR REPLACE FUNCTION ..._で既存の関数定義を変更できます。関数が同じ関数と辞書を使用し続けることを確認してください。そうすると、インデックスはREINDEXなしで適切に機能し続けます。 （ただし、インデックスで使用されている間は、関数をDROPすることはできません。）

アクセントのないモジュールをシステムカタログ_pg_catalog_に移動することもできます。その後、すべてが自動的に_search_path_に入ります。 あなたはそうすることになった 、しかし私はそうしますではありませんそれを擁護します。システムカタログをいじることは一般的にはお勧めできませんし、何をしているか正確に知らなければインストールを簡単に損なう可能性があります。

関連：

検索辞書「unaccent」は、フルテキスト検索でテキスト検索設定によって定期的に使用されます。関連：

2
Erwin Brandstetter