問題タブ [postgresql-9.6]

データベースを 9.6.0 から 9.6.1 にアップグレードする予定ですが、多くのテーブルスペースを持つ 1 つのデータベースをアップグレードしているときに問題が見つかりました。アップグレードは次のエラーで失敗します

「テーブルスペースを使用している場合、同じシステム カタログ バージョンとの間で移行できません」

問題が 1 つあります。クエリが "CREATE TABLE" で囲まれている場合、クエリ処理の並列処理がデータベースで機能するようになりました。

プレーンな SELECT は完全に並行して処理されるため、非常に高速です。並列処理は EXPLAIN 出力にも表示され、「トップ」モニタリングでバックグラウンド ワーカーも確認できます。したがって、9.5ページよりもはるかに優れています。

しかし、CREATE TABLE で同じ SELECT を使用すると、並列ではなく長時間実行されます。pg 9.5 よりもはるかに遅いです。この場合の並列処理は EXPLAIN 出力には表示されず、OS で実行されているバックグラウンド ワーカーはありません。"force_parallel_mode" = ON に設定しようとしましたが、変更はありません。

CREATE TABLEでも並列処理を使用するために、標準設定から変更する必要がある、私が見逃した魔法の設定はありますか? それとも、これは「設計による」予想される動作ですか?

更新:OK、「設計による」ようです-PostgreSQLで操作を書き込むためのCTEでの並列クエリ

しかし、その場合、CREATE TABLE as SELECT は、9.5 と比較して 9.6 で非常に悪いパフォーマンスを与えるようです...

2. 更新: PostgreSQL 9.6 では 9.5 よりも高い work_mem の設定が必要なようです - 実行が不十分なクエリのクエリ プランをいじったところ、セッションで work_mem 設定を変更するだけで、"Sort (cost=807568233.23..807568267.50 rows= 13709 width=105)" for work_mem=32MB から "Sort (cost=151127.62..151161.89 rows=13709 width=105)" for work_mem=64MB...

PostgreSQL 9.6.1 で dblink 拡張機能を使用してタスクを並列実行すると奇妙な問題が発生します。場合によっては、接続中のタスクが既に終了していることを拡張機能が認識できず、結果を待っているようです。したがって、PG 9.5 で完全に実行されていたプログラムが、PG 9.6 では無期限にハングし続けることがあります。

手順：

• 「perform dblink_connect」を使用して接続が開かれます
  
• クエリは「dblink_send_query」を使用して送信されます
  
• 他のタスクは別の接続に送信されます
  
• プログラムは最初の接続を取得し、「dblink_get_result」を発行して出力を待ちます
  
• 2 番目の接続などの後 - これらの接続の一部は既に終了しているため、「dblink_get_result」の開始直後に結果が得られるはずですが、場合によっては PG 9.6 では機能せず、チェックがハングするだけです...

私が認識していない PG 9.6 での dblink 動作の変更はありますか?

構成 ：

• AWS
• Ubuntu Linux
• 実行中の docker : docker -v= Docker バージョン 1.12.1、ビルド 23cf638
• Postgresql -"PG_MAJOR=9.6", "PG_VERSION=9.6.0-1.pgdg80+1"
• オドゥー -"ODOO_VERSION=9.0","ODOO_RELEASE=20160726"

問題 ：

• odoo にログインできました。ログインすると、ウェブサイトのページが開きます。今までは問題ありません。以前にインストールした「雇用」、「メモ」などのオプションに移動した後、単純な空白のページが他の何もない場所に共有として表示されます。
• 参考までに、それは約 100 日間スムーズに実行されていましたが、その後、最近コンテナーが実行を停止しました [aws インスタンスのディスクがいっぱいになった可能性があります]。スペースを作ってコンテナを再起動しました。
• 同じイメージから再作成された場合、db [postgresql 9.6] と odoo [9] の新しいクリーンなインスタンスは正常に動作します。
• このコンテナとそのクローンを使用しても、古いものでも新しいものでも、データベースでは機能しません。
• 以前は純粋な html ページがロードされていましたが、Linux、Docker、コンテナを数回再起動した後、魔法のように適切なログイン ページが表示され始めました。

私の結論：

• ログインできたので、db接続はOKです。

pg_xlog フォルダーのサイズを制限するように PostgreSQL 9.6 データベースを構成しようとしています。この問題または同様の問題に関する多くのスレッドを読みましたが、試したことはありません。

Postgresql 9.6 サービス インスタンスのセットアップ スクリプトを作成しました。initdb を実行し、Windows サービスを登録して開始し、空のデータベースを作成して、データベースにダンプを復元します。スクリプトが完了すると、データベース構造は正常になり、データはそこにありますが、xlog フォルダーには既に 55 個のファイル (880 mb) が含まれています。

フォルダーのサイズを小さくするために、wal_keep_segments を 0 または 1 に設定し、max_wal_size を 200mb に設定し、checkpoint_timeout を減らし、archive_mode をオフに設定し、archive_command を空の文字列に設定してみました。pg_settings をクエリすると、プロパティが正しく設定されていることがわかります。

次に、SQL を介してチェックポイントを強制し、データベースをバキュームし、Windows サービスを再起動して pg_archivecleanup を試しましたが、実際には何も機能しませんでした。xlog フォルダーは 50 ファイル (800 mb) に縮小されましたが、構成で設定した 200 mb の制限にはほど遠いものでした。

他に何を試すべきかわかりません。誰かが私が間違っていることを教えてくれたら、とても感謝しています。さらに情報が必要な場合は、喜んで提供します。

どうもありがとう

Mac で csv ファイルを pgAdmin4 にインポートする際に問題が発生しました。ファイルが見つからないだけです。これは非常に単純なので、設定に失敗しただけの設定があることを願っています。

テーブルのデータのインポート/エクスポート機能には、次のような [インポート/エクスポート] ダイアログがあります。

ただし、ファイルが見つかりません。

ファイルへの間違ったパスを指定すると、そのエラーは標準の python エラーのように見えます。しかし、それは正しいです - それはファイルがある場所です: '/tmp/person616.csv' - 私は名前/パスを入力さえしませんでした.私はそれを参照しました.

これは他の誰かに起こりましたか？それを修正する方法を知っていますか？

オンラインで見つけたすべてのアドバイスに従いましたが、これを機能させることができないようです。

バックグラウンド：

RHEL 6.8 を実行しているサーバーに Postgresql 9.6 をセットアップしました。Linux Mint 17.3 を実行しているクライアントから、このサーバーの Postgresql サービスにリモート接続しようとしています。

私が試したこと：

1) postgresql.conf に、次の 2 行を追加しました。

2) pg_hba.conf に、次の行を追加しました。

3) その後、postgresql サーバーを再起動しました。

4) 念のためポート 5432 への接続を許可するルールをファイアウォールに追加しました。

5) 実行netstat -tulpn | grep 5432して、次の出力を得ました。

クライアントからサーバーに接続するために実行したコマンドは次のとおりです。

そして、次の出力を得ました。

質問:

この問題をさらにトラブルシューティングするには、他に何ができますか?

一連の具体化されたビューを熱心に同期するためのカスタム ワークフローを作成して自動化しました。いくつかの異なるアプローチ (1 対多の関係) を試した結果、最も信頼できる同期ワークフローは、影響を受けた可能性のあるすべてのレコードを削除してから、新しいレコードを挿入することであることがわかりました。

注: some_query_generating_some_materialized_view は、実行にかなりの量のリソースを必要とする複雑な読み取り操作です。さらに、 some_materialized_view は、いくつかの外部キーとその他の制約で大量にインデックス化されています。

これは非常に扱いが重いと感じます。このワークフローには、過剰な削除操作と挿入操作が伴いますが、削除されたレコードの一部が同一であるか、UPDATE の候補になるほど類似している可能性があるため、多くの場合不要です。

私は次のようなものを好むでしょう：

問題はON CONFLICT ... DO UPDATE ... WHERE ... RETURNING節にあります。

この質問で対処されているように: How to use RETURNING with ON CONFLICT in PostgreSQL?

RETURNING 句は、影響を受けるレコードのみを返します。そのため、影響を受けていないレコードは返されないため、(上記の例では) 不適切に削除されます。

実際にすべてのレコードを返す唯一の方法は、句RETURNINGを削除して同一のレコードを不必要に更新するWHERE some_materialized_view <> EXCLUDEDか、別の句で some_query_generating_some_materialized_view を再度実行することEXCEPTです...両方のオプションも理想的ではありません。

それで、私は何が欠けていますか？他に利用可能なオプションはありますか? そうでない場合、一般に、不要な UPDATE よりも複雑でリソースを大量に消費する読み取り操作を実行することをお勧めします (関連するインデックスのメンテナンスとチェックの制約を思い出してください)。

注：EXPLAIN ANALYZEこれは単一のクエリに固有のものではなく、一般的な質問であるため、結果は含めていません。保守性と健全性のために、このプロジェクトは一貫性を保つ必要があり、この手法はさまざまな構造とユースケースのテーブルで数回使用されます (読み取り負荷が高いものもあれば、書き込み負荷が高いものもあります)。

私の Postgres 9.6 環境で、「MERGE INTO」クエリを実行しようとすると、次のエラーがスローされます。

MERGEクエリをサポートしていないようです。しかし、Google で調べてみると、バージョン 9.1 以降の Postgres で MERGE がサポートされているようです。

ここで何がうまくいかないのか教えてください。

編集: 以下は、Postgres で MERGE サポートを見つけたソースです。

https://wiki.postgresql.org/wiki/MergeTestExamples