タグ付けされた質問 「postgresql-9.2」

PostgreSQLバージョン9.2

3
新しいユーザーがテーブルを作成できるのはなぜですか?
新しく作成したユーザーがデータベースに接続した後にテーブルを作成できるのはなぜだろうかと思っています。私は1つのデータベースを持っていますproject2_core: postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges ---------------+--------------+-----------+-------------+-------------+------------------------------- postgres | postgres | SQL_ASCII | C | C | project2_core | atm_project2 | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | project2=CTc/project2 template0 | postgres | SQL_ASCII | C | C | …

5
PostgreSQLで非常に遅いDELETE、回避策?
PostgreSQL 9.2には、約70個のテーブルを持つメインスキーマと、それぞれ30個のテーブルからなる可変構造のクライアントごとのスキーマを持つデータベースがあります。クライアントスキーマには、メインスキーマを参照する外部キーがあり、その逆はありません。 以前のバージョンから取得した実際のデータをデータベースに入力し始めたところです。メインスキーマの非常に中央のテーブルで一括削除を行う必要があったときに、DBは約1.5 GBに達しました(数週間で数十GBに達すると予想されています)。関係するすべての外部キーは、DELETE CASCADEでマークされます。 これに長い時間がかかることは驚きではありませんでしたが、12時間後には、最初からやり直してDBを削除し、移行を再開する方が良いことが明らかになりました。しかし、後でDBが稼働し、さらに大きくなったときにこの操作を繰り返す必要がある場合はどうなりますか?より高速な代替方法はありますか? 中央テーブルから最も遠いテーブルから開始し、テーブルごとに依存する行を削除する依存テーブルを参照するスクリプトを書いたら、もっと速くなるでしょうか? 重要な詳細は、いくつかのテーブルにトリガーがあることです。

1
ディスクスペースをオペレーティングシステムに戻すVACUUM
VACUUM通常、特別な場合を除いて、オペレーティングシステムにディスク領域を返しません。 ドキュメントから: 標準形式でVACUUMは、テーブルとインデックス内の無効な行バージョンを削除し、将来の再利用に使用可能なスペースをマークします。ただし、テーブルの最後の1つ以上のページが完全に空になり、排他的なテーブルロックを簡単に取得できる特別な場合を除いて、オペレーティングシステムに領域を返しません。対照的に、VACUUM FULLデッドスペースのない完全に新しいバージョンのテーブルファイルを書き込むことにより、アクティブにテーブルを圧縮します。これにより、テーブルのサイズが最小になりますが、時間がかかる場合があります。また、操作が完了するまで、テーブルの新しいコピー用に追加のディスク領域が必要です。 問題は、このデータベースの状態をどのone or more pages at the end of a table become entirely freeように達成できるかということです。これはを介して行うことができますがVACUUM FULL、実装するのに十分なスペースがありません。他の可能性はありますか?

4
Postgresがすでに使用されているPK値を生成するのはなぜですか?
私はDjangoを使用していますが、時々このエラーが発生します: IntegrityError:重複キー値が一意の制約 "myapp_mymodel_pkey"に違反しています 詳細:キー(id)=(1)は既に存在します。 実際、私のPostgresデータベースには、主キーが1のmyapp_mymodelオブジェクトがあります。 Postgresが再びその主キーを使用しようとするのはなぜですか?または、これはおそらくアプリケーション(またはDjangoのORM)がこれを引き起こしているのでしょうか? この問題は、ちょうど3回続けて発生しました。私が見つけたのは、それが発生した場合、特定のテーブルの行で1回以上発生し、その後は発生しないことです。これは、数日間完全に停止する前にすべてのテーブルで発生し、発生したテーブルごとに少なくとも1分程度発生し、断続的にのみ発生するようです(すぐにすべてのテーブルが発生するわけではありません)。 このエラーが非常に断続的である(2週間で3回程度しか発生しなかった-DBに他の負荷がなく、アプリケーションをテストしているだけである)ため、低レベルの問題に非常に警戒しています。

4
Postgres 9.2にアップグレードするときに古いポストマスターをシャットダウンできません
Postgres 9.2.2(9.1.4から)にアップグレードしています。次を使用してDBをアップグレードしようとすると: pg_upgrade -b /usr/local/Cellar/postgresql/9.1.4/bin -B /usr/local/Cellar/postgresql/9.2.2/bin -d /usr/local/var/postgres91 -D /usr/local/var/postgres 次のエラーメッセージが表示されます。 Performing Consistency Checks ----------------------------- Checking current, bin, and data directories ok There seems to be a postmaster servicing the old cluster. Please shutdown that postmaster and try again. Failure, exiting サーバーを停止しようとしていますが、アップグレードコマンドが機能しません。古いポストマスターをシャットダウンする方法は?


2
スーパーユーザーにならずにpg_stat_activityで別のセッションのクエリを表示するにはどうすればよいですか?
Postgresql 9.2データベースがあります。このデータベースに2人のユーザーが作成されます。スーパーユーザーとして次のクエリを実行すると、すべてが表示されます。 select * from pg_stat_activity ただし、スーパーユーザーとして接続せずに同じ結果を達成することは可能ですか? スーパーユーザーが表示できる結果を得るには、どの特権/ロールを付与/作成する必要がありますか?

1
SELECT *が名前ですべての列を(異なる列順序で)選択するよりもずっと速いのはなぜですか?
列a、b、c、d、e、f、g、h、i、j、kがあるテーブルでは、次のようになります。 select * from misty order by a limit 25; Time: 302.068 ms そして: select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25; Time: 1258.451 ms 列ごとの選択をできるだけ速くする方法はありますか? 更新: テーブルにインデックスがなく、新しく作成されたもの これはEXPLAIN ANALYZEで、あまり役に立たないようです: explain analyze select * from misty order by a limit 25; Limit (cost=43994.40..43994.46 rows=25 width=190) (actual time=404.958..404.971 rows=25 loops=1) …

2
UPDATE CASCADEを使用したFK制約によって操作が発生した場合、FOR EACH STATEMENTトリガーはどのくらいの頻度で実行されますか?
で定義されたテーブルtのトリガーは、FOR EACH STATEMENTを実行すると1回実行されることを理解していますUPDATE t ...。 では、をtで定義しFOREIGN KEY ... REFERENCES a ... ON UPDATE CASCADE、でN行を更新aすると、トリガーが1回呼び出されるのですか、それともN回呼び出されるのですか? 別の言い方をすると、FK制約によってカスケードされたテーブルへの変更は、単一のUPDATE、または一連のUPDATEのようなものですか?

1
pg_activityで「トランザクション分離レベルの表示」を使用して複数のクエリを取得する
PostgreSQLサーバーを運用環境で使用しています。 次のようなクエリを実行すると select * from pg_stat_activity 私のサーバーでは、次のようなクエリの98%を取得しています SHOW TRANSACTION ISOLATION LEVEL サーバーは100接続しか受け入れないため、先に進むことができません。 なんでこんなことが起こっているの?これらのクエリをすべてブロックするにはどうすればよいですか?

1
PostgreSQLデータベースへのリモートアクセスのタイムアウトオプションはありますか?
私が働いている経由でリモートのPostgreSQLデータベースにpgAdminでIII。pgAdminで何もせずにそれほど長くない期間(たとえば10〜15分)が経過すると、接続は自動的に期限切れになります。そのため、再接続するかどうかを尋ねるエラーメッセージが表示されます。これには約10秒かかります。データベース構造が崩れるため、以前開いていたスキーマを再度開く必要があります。 タイムアウトパラメータをどこかに変更して、接続の有効期限が長くなるのを防ぐ方法はありますか?

1
`pg_lsclusters`がPostgresクラスタをリストしないのはなぜですか?
apt-getPostgres 9.2.4 をインストールしました(PPAを使用)。 私が使用pg_dropcluster --stop 9.2 main私はちょうど取り付けられた別個のSSDボリューム(ラックスペースブロック・ストレージ・ボリューム)に新しいクラスタを作成する方法を意図するので、デフォルトデータベースクラスタを除去します。 SSDボリュームにデータが存在する新しいクラスターを作成して開始しました(psその新しいクラスターで実行されているすべての通常のPostgresプロセスが表示され、Postgresシェルを開いてSQLを実行できます(つまり、正常に実行されています)。実行pg_lsclustersすると、何も表示されません。 main私はそれを削除する前に、クラスタがうまく上場しました。新しいクラスターが実行されているのに、なぜ表示されないのですか?サーバーを再起動しました(念のため)。

1
LISTEN / NOTIFY特権
私はpostgresデータベースを1つ持ち、2人のユーザーがいます。アリスとボブ。 NOTIFY alice_channel 'sensitive data'ボブがLISTENチャネル名が「alice_channel」であると推測するだけでこっそりと侵入することなく、できるようにしたいと思います。 実際には、チャネル名を推測することは非常に困難ですが、これはせいぜいあいまいさによるセキュリティです。 データベースユーザーがLISTEN&を使用する(乱用する)のを防ぐ方法はないと私は信じていますNOTIFYか?つまり、付与または取り消すことができる関連する特権はないようです。 これは行き止まりですか?

1
CLUSTERのパフォーマンスへの影響
Postgres 9.2データベースを最適化して、日付制限のあるクエリを高速化しようとしています。 私はtimestamp列を持っていますが、たいていはいつか尋ねているのでtimestamp、date解析するためのインデックスを作成しました: CREATE INDEX foo_my_timestamp_idx ON foo USING btree ((my_timestamp::date) DESC); 次に、パフォーマンスを向上させるために、CLUSTER foo上記のインデックスを使用してテーブルを作成します。 CLUSTER foo USING foo_my_timestamp_idx; SQL-CLUSTERのマニュアルによると、テーブル インデックス情報に基づいて物理的に並べ替えられます テーブルのPKを使用する他のクエリのパフォーマンスに影響があるかどうかを知ります(としましょうid_foo)。欠点はありますか?

1
CTE INSERTの結果を使用して一意のID値を提供するINSERT
古いデザインのデータを新しいデザインに変換するジョブを書いています。このプロセスでは、挿入から別のテーブルへのIDを取得し、それをターゲットテーブルへの挿入で使用する必要があります。 CREATE TABLE t1 { t1_id BIGSERIAL, col1 VARCHAR }; CREATE TABLE t2 { t2_id BIGSERIAL, col2 VARCHAR, -- renamed from col1 to avoid confusion t1_id BIGINT REFERENCES t1.t1_id }; 次の形式に一致するSQLが定義されています。 WITH ins AS ( INSERT INTO t1 (t1_id) VALUES (DEFAULT) RETURNING t1_id ) INSERT INTO t2 (col1, t1_id) SELECT …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.