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

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 閉じた3年前。 PgAdmin 4 1.0がリリースされたばかりですが、Linuxのダウンロードページには、yumインストーラーへのリンクしかありません。 debインストーラーを作成する計画があるかどうかは誰でも知っていますか？または、すでにある場合は？

13 postgresql  ubuntu  pgadmin  debian 

今朝、私はAWS RDS上のPostgreSQLデータベースのアップグレードに関与しました。バージョン9.3.3からバージョン9.4.4に移行したかったのです。ステージングデータベースでアップグレードを「テスト」しましたが、ステージングデータベースははるかに小さく、マルチAZを使用しません。このテストはかなり不十分であることが判明しました。 運用データベースではマルチAZを使用しています。過去にマイナーバージョンアップグレードを行ったことがあります。その場合、RDSは最初にスタンバイをアップグレードしてからマスターに昇格します。したがって、フェイルオーバー中に発生するダウンタイムは最大60秒です。 メジャーバージョンのアップグレードでも同じことが起こると想定していましたが、それは間違いです。 セットアップに関する詳細： db.m3.large プロビジョンドIOPS（SSD） 300 GBのストレージ、そのうち139 GBが使用されます RDS OSのアップグレードは未解決であり、ダウンタイムを最小限に抑えるためにこのアップグレードをバッチ処理したかった アップグレードの実行中に記録されたRDSイベントは次のとおりです。 データベースCPUは08:44から10:27の間に最大になりました。この時間の多くは、アップグレード前およびアップグレード後のスナップショットを取るRDSによって占有されているように見えました。 AWSのドキュメントには、それらを読んでから、我々のアプローチの明らかな欠陥は、我々はのコピーを作成しなかったことであることは明らかであるものの、そのような影響を警告していない生産マルチAZセットアップでデータベースをし、としてそれをアップグレードしよう試運転 一般に、RDSが何をしていて、どれくらいの時間がかかる可能性があるかについて、RDSがほとんど情報を提供しなかったため、非常にイライラしていました。（繰り返しになりますが、試用版を実行すると助かります...） それとは別に、この事件から学びたいので、ここに質問があります： RDSでメジャーバージョンアップグレードを行う場合、この種のことは正常ですか？ 将来、最小のダウンタイムでメジャーバージョンアップグレードを行いたい場合、どうすればよいでしょうか？レプリケーションを使用してシームレスにするための賢い方法はありますか？

13 postgresql  amazon-rds 

顧客とスコア（この場合は無関係で、さまざまな要因に基づいています。顧客は複数のスコアを持つことができます）を含むテーブルがあります。 customer_id | score | score_giver_id ==================================== 1 | 100 | 1 1 | 102 | 1 1 | 101 | 1 1 | 140 | 1 2 | 131 | 3 1 | 44 | 1 3 | 223 | 1 3 | 1 | 2 3 | 201 …

13 postgresql  postgresql-9.4 

次の2つのチュートリアルに従って、DBを作成しました。 完全な特権を持つユーザーリンク 読み取り専用のユーザーリンク その後、CJ Estelのチュートリアルから、「新しいユーザーに明示的にテーブルを提供しなかったとしても、テーブルを作成する機能を継承している可能性がある」というヒントを受け取りました。案の定、読み取り専用ユーザーはテーブルを作成して所有することができます！ CJ Estelは根本原因、つまりテンプレートデータベースを非常によく指摘しています。しかし、テーブルを作成する機能は、postgresql.orgでホストされているものを含む「読み取り専用ユーザーpostgres」をグーグルで取得するほとんどのチュートリアルを損ないます。ユーザーには読み取り専用以上の権限があります！ 新しいユーザーにこの機能があるのはなぜですか？この特権を取り消した後、データベースはそのユーザーに対して本当に読み取り専用ですか？

13 postgresql  permissions 

データベースで毎日実行しているバッチクエリがあります。ただし、アイドル状態のままになっているようで、何が起こっているのかをデバッグするのが非常に困難です。 クエリは、同時に挿入されるテーブルの集計であり、何らかの問題に関連していると推測しています。（集計は前日のデータに基づいているため、挿入は結果に影響しません。） 手がかり これは、sqlalchemyを使用してPythonスクリプト内で実行しています。ただし、トランザクションレベルを自動コミットに設定しているので、トランザクション内に物事がラップされるとは思いません。一方、sqlターミナルでクエリを手動で実行しても、クエリがハングすることはありません。 照会することによりpg_stat_activity、クエリは最初としてデータベースに入ってきますstate='active'。おそらく15秒後に、状態が「アイドル」に変わり、さらにxact_startがに設定されNULLます。待機フラグがtrueに設定されることはありません。 sqlalchemyのトランザクションレベルの自動コミットを理解する前に、代わりに状態'idle in transaction'ではなく状態でハングし'idle'ます。そして、その変更を行ってからハングする可能性がわずかに少なくなりますか？ 私はこれ以上深く掘る準備ができていないように感じます。明確な答えを出さずに、さまざまな状態や関連するpostgres内部についてさらに説明するフィードバックも歓迎します。

13 postgresql  postgresql-9.3 

私は最近、サーバーの一人のユーザーとの定期的なアクセス権を共有したいと思ったし、私は簡単なことを実現CREATE USERし、GRANT ALL ON DATABASEコマンドは彼が単純で実行できなかったSELECTデータのを。 特定のデータベースのすべてのテーブルへの権限を特定のユーザーに付与しpublicたいのですが、何らかの特権を許可するかどうかわからないため、スキーマ全体へのアクセスを許可するのが最善のアイデアかどうかわかりませんエスカレーション。他の方法はありますか？

13 postgresql  best-practices  permissions  access-control 

Ubuntu 14.04にPostgres 9.3をインストールしようとしていますが、起動時に厄介なエラーが発生します。ここに私が見ているものがあります： $ sudo service postgresql restart * Restarting PostgreSQL 9.3 database server * Error: could not exec /usr/lib/postgresql/9.3/bin/pg_ctl /usr/lib/postgresql/9.3/bin/pg_ctl start -D /var/lib/postgresql/9.3/main -l /var/log/postgresql/postgresql-9.3-main.log -s -o -c config_file="/etc/postgresql/9.3/main/postgresql.conf" : [fail] そこで、この出力でログファイルをチェックしました。 2015-01-05 21:50:05 EST LOG: database system was shut down at 2015-01-05 21:50:03 EST 2015-01-05 21:50:05 EST LOG: …

13 postgresql  errors  error-log 

私はPostgres 9.3.5を使用しており、データベースに大きなテーブルがあります。現在は2500万行以上あり、急速に大きくなる傾向があります。次のような簡単なクエリを使用して、特定の行（すべてunit_idのsに最新のもののみを含む）を選択しようとしていますunit_timestamp。 SELECT unit_id, max(unit_timestamp) AS latest_timestamp FROM all_units GROUP BY unit_id; インデックスがない場合、このクエリの実行には約35秒かかります。定義されたインデックス（CREATE INDEX partial_idx ON all_units (unit_id, unit_timestamp DESC);）を使用すると、クエリ時間は約（わずか）19秒に短縮されます。 クエリをさらに短い時間（ほんの数秒など）で実行できるようになるのではないかと考えています。その場合、クエリをさらに最適化するにはどのような手順を実行する必要がありますか。 テーブル構造のダンプは次のようになります。 CREATE TABLE "all_units" ( "unit_id" int4 NOT NULL, "unit_timestamp" timestamp(6) NOT NULL, "lon" float4, "lat" float4, "speed" float4, "status" varchar(255) COLLATE "default" ) ALTER TABLE "all_units" ADD PRIMARY …

13 postgresql  performance  index  query-performance 

別のテーブルからテーブルを更新する必要があり、すべての列を更新する必要があります。SET句のすべての列をリストする以外に、それらを一度にすべて更新する方法はありますか？このような： update tableA set * = tableB.* from tableB where tableA.id = tableB.id 私はpsqlで試しましたが、うまくいきません。次のようにすべての列をリストする必要があります。 update tableA set c1 = tableB.c1, c2 = tableB.c2, ... from tableB where tableA.id = tableB.id tableB作成された使用create .. like tableA。したがって、それらは基本的に同一です。そして、私がそれをしている理由は、.csvデータを一時テーブルにロードしてから、の新しいデータに基づいてtableB更新する必要があるからです。ロックをできるだけ少なくする必要があり、整合性を維持する必要があります。「削除してから挿入」が良い選択肢かどうかわかりませんか？tableAtableBtableAtableA

13 postgresql  update 

組み合わせのPostgresの道であるIS DISTINCT FROMとANYかと同じ結果を得るための他のいくつかのきちんとした方法は？ select count(*) from (select 'A' foo union all select 'Z' union all select null) z where foo <> any(array[null, 'A']); count ------- 1 (1 row) select count(*) from (select 'A' foo union all select 'Z' union all select null) z where foo is distinct from any(array[null, 'A']); …

13 postgresql  null  postgresql-9.3 

テーブルが与えられた場合： Column | Type id | integer latitude | numeric(9,6) longitude | numeric(9,6) speed | integer equipment_id | integer created_at | timestamp without time zone Indexes: "geoposition_records_pkey" PRIMARY KEY, btree (id) このテーブルには2000万件のレコードがありますが、比較的多くはありません。ただし、シーケンシャルスキャンが遅くなります。 max(created_at)それぞれの最後のレコード（）を取得するにはどうすればよいequipment_idですか？ 私はこのトピックの多くの回答を読んだいくつかのバリエーションを使用して、次の両方のクエリを試しました： select max(created_at),equipment_id from geoposition_records group by equipment_id; select distinct on (equipment_id) equipment_id,created_at from geoposition_records order by …

13 postgresql  performance  index  greatest-n-per-group 

Ubuntu 12.04および13.04を実行している2つのVMのAPTリポジトリからPostgreSQL 9.3を正常にインストールしましたが、Ubuntu 12.04を実行しているホストマシンに正しくインストールできません。 インストール（今度は）はうまくいったようですが、おそらく私には理解できないエラーがあります： * No PostgreSQL clusters exist; see "man pg_createcluster" Setting up postgresql-9.3 (9.3.0-2.pgdg12.4+1) ... Creating new cluster 9.3/main ... config /etc/postgresql/9.3/main data /var/lib/postgresql/9.3/main locale en_US.UTF-8 port 5432 update-alternatives: using /usr/share/postgresql/9.3/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode. だから、私は自分をPostgreSQLユーザーとして追加しようとしますが、私はこれを取得します： createuser: could not connect to database postgres: could …

13 postgresql  postgresql-9.3 

200 GBのサイズがデータで占められ、180 GBのサイズが6つのインデックスで占められているテーブルがあります。それは30％肥大化していますので、それによって占有されている不要なスペースを回収したいと思います。job_id_idxインデックスでクラスター化されます。 スペースを再利用するには、clusterコマンドまたはvacuum fullコマンドを使用する必要がありますか？ この2つのコマンドの違いは何ですか？ vacuum fullある列の順序はclusterコマンドと同じですか？ 両方のコマンドでインデックスが再作成されますか？ 私の場合、どちらが速くなりますか？ PostgreSQLデータベースのバージョンは9.1です

13 postgresql  postgresql-9.1  clustered-index  vacuum 

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 サーバーを停止しようとしていますが、アップグレードコマンドが機能しません。古いポストマスターをシャットダウンする方法は？

13 postgresql  postgresql-9.2 

Postgresql 8.1データベースがあります。一つのテーブルでは、3つの列がありますfirst_name、last_name、display_name。 これは、デフォルト値の設定が可能であるdisplay_nameことにはfirst_name + " " + last_name？

13 postgresql