サーバー側でクエリの実行を中断するには SIGINT を当該プロセス( ps や pg_stat_activity から探す)に送ります(kill -INT PID)が、これではセッションは切断されません。メンテナンスなどで切断して欲しい場合には pg_terminate_backend(procpid) を使います。 当該の PID がわかっている場合には
![PostgreSQL のサーバー側でセッションを切断する方法 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/05647484eab921cf8505d68f467e59e166c224a9/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9UG9zdGdyZVNRTCUyMCVFMyU4MSVBRSVFMyU4MiVCNSVFMyU4MyVCQyVFMyU4MyU5MCVFMyU4MyVCQyVFNSU4MSVCNCVFMyU4MSVBNyVFMyU4MiVCQiVFMyU4MyU4MyVFMyU4MiVCNyVFMyU4MyVBNyVFMyU4MyVCMyVFMyU4MiU5MiVFNSU4OCU4NyVFNiU5NiVBRCVFMyU4MSU5OSVFMyU4MiU4QiVFNiU5NiVCOSVFNiVCMyU5NSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YmFhMTUwYTkxMjYxOGE2YzhkNDU5MzE0OTkzYjk3YTg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5dGVyYW9rYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MWM1MGMzNDJlYTA1NDlhMTE1NDgzMTZlNGVlMWFhODQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D9e87b495451f31a1591d36b5372cbe2f)
サーバー側でクエリの実行を中断するには SIGINT を当該プロセス( ps や pg_stat_activity から探す)に送ります(kill -INT PID)が、これではセッションは切断されません。メンテナンスなどで切断して欲しい場合には pg_terminate_backend(procpid) を使います。 当該の PID がわかっている場合には
概要 PostgreSQLでテーブルを作成します。 構成 サーバ構成 OSバージョン Red Hat Enterprise Linux 5.9 x86_64 パッケージ一覧 postgresql90-9.0.8-1PGDG.rhel6.x86_64.rpm postgresql90-libs-9.0.8-1PGDG.rhel6.x86_64.rpm postgresql90-server-9.0.8-1PGDG.rhel6.x86_64.rpm 手順 テーブルの作成 テーブル作成前の確認 データベースユーザ user1 が所有者のデータベース testdb1 にテーブル tbl1 を作成します。 テーブル作成する前にメタコマンドで現状のテーブル一覧を確認します。 まだテーブルを作成していないので、「リレーションがありません。」と表示されます。 -bash-3.2$ psql -U user
PostgreSQLのプロセスを停止させる方法のメモ くっそ重いクエリを流してしまった! CPU・メモリをゴリゴリ喰ってる!! やばいッッッ! こんな場合にもプロセスを止めるといい トランザクション中にコミットもロールバックもせず放置され他のプロセスがロック開放待ちになった 高コストの処理を実行してしまい、結果を取得する前に終わらせてしまいたい そんな時の対処法をご紹介します。 さぁ、いらないプロセスをブッKillそう! 事前にプロセスIDを調べておきましょう。 postgres=# SELECT * from pg_stat_activity; -[ RECORD 1 ]----+-------------------------------- datid | 12870 datname | postgres pid | 16883 usesysid | 10 usename | pos
PostgreSQL の COPY コマンドと SQL だけを使って、いろいろなデータをテーブルにインポートする方法についてまとめてみました。 プログラミングが得意で、データベースはあんまり得意じゃないっていう人だと、データをインポートする際に、何でもかんでもゴリゴリとプログラムを書いて済ませてしまうことが多いかと思いますが、COPY コマンドと SQL だけでも結構複雑なデータをインポートすることができたりしますので、簡単に紹介してみます。 シーケンスをインクリメントしながらインポートする 例えば、次のような感じのテーブルと user_no_seq というシーケンスがあったとします。 user_no | user_name | total_score ---------+-----------+------------- 1 | A | 120 2 | B | 130 3 | C | 9
2014年02月07日11:28 カテゴリpostgresql Postgresqlのシーケンスを再設定する postgresqlのシーケンス値は、mysqlと違って指定カラムの最大値を取ってくれるのではなく、別に保存してある「最大値」を設定するようになっている。 SQLでinsertして行く分には基本問題ないけれど、CSVなどからインポートした場合、保存した値とずれてしまい、SQLからのinsert時に "duplicate key value violates unique constraint" などと怒られてしまうことがある。 これ再設定するには select setval('hogehoge_id_seq',(select max(id) from hogehoge)); みたいな感じにする。 後半のselect分はテーブルのidの最大値を取る、と言うことで、この部分を直接数字を
概要 psqlでデータベースに接続した後で実行可能なPostgreSQL特有のメタコマンドについて紹介します。 代表的なメタコマンドについて実行例を表示していますが、PostgreSQLをインストールした直後に 実行したメタコマンドなので、ユーザオブジェクトはまだありません。 ほとんどがシステムオブジェクトの表示のみですが、ご了承ください。 構成 サーバ構成 OSバージョン Red Hat Enterprise Linux 5.9 x86_64 パッケージ一覧 postgresql90-9.0.13-1PGDG.rhel5.x86_64.rpm postgresql90-libs-9.0.13-1PGDG.rhel5.x86_64.rpm postgresql90-server-9.0.13-1PGDG.rhel5.x86_64.rpm 手順 psqlの起動・停止 psqlの起動(データベ
図1はPostgreSQLのファイル構造を示したものです。図中、四角で示したものは論理的な構造を意味し、円柱は物理的に実在するファイルを示しています。 最初にPostgreSQLをインストールした後に、データベース領域を初期化(initdbコマンドを実行)した直後には、templete0,templete1というデータベースが作成され、基本構造が生成されます。 ここで言う「データベース」はOracleでいうそれとは違う意味なので注意して下さい。このとき生成されるデータベース基本構造全体を指して"データベース・クラスタ"と言います。 templete0とtemplete1は文字通りユーザが作成するデータベースの雛形で、ユーザが新規にデータベースを作成した場合は、templete1がコピーされ、同じ高さに並列して作成されます。 図1には示していませんが、システムカタログは$PGDATA/glo
PostgreSQLでダンプするには $pg_dump データベース > dump.sql $pg_dump データベース -U ユーザ -h ホスト -t テーブル > dump.sql とかまぁやれば良いんだけど、テーブルの中の一部分。さらに言えば、SELECTで絞った状態のデータがCSVとして欲しいなぁというときには、psqlコマンドを使って以下のようにすれば良い。 $psql データベース -U ユーザ -h ホスト -c "SELECT * FROM table WHERE 1=1;" -A -F,> dump.txt psqlのオプションで A と F を使ってやるとできる。 Aオプション:テーブルの要素を出力するときの均等割り付けを行いません。 F(separator)オプション:separator をフィールドセパレータとして使用します。 デフォルトは ASCII の縦棒
PostgreSQLでラージオブジェクトを利用する際のメモです。まだ書きかけです。内容については保証できません。詳細内容は参考文献を参照してください。 ラージオブジェクトの使用方法 コマンドライン(psql)よりラージオブジェクトを作成する postgresqlに付属のドキュメントより Can not access : import.console プログラム(libpq)よりラージオブジェクトを作成する postgresqlに付属のドキュメントより Oid importFile( PGconn *conn, // (I/ ):postgresql 接続子 char *filename, // (I/ ):読込み対象ファイル char *errTxt // ( /O):エラー時の内容が格納される。 ) { Oid lobjId; int lobj_fd; char buf[BUFSIZE]
PostgreSQLでDBの移行をすることがあったのだけれども、 移行元DB(含むサーバlocale)の文字コードがかつての主流EUC-JPで、 移行先DBの文字コードがUTF-8だったのでpg_dumpの際にちょっと困ったのでメモ。 dumpファイルがプレーンテキストならばdumpファイル自体の文字コードを変換したあとにdumpファイル内に書かれている"EUC-JP"を"UFT-8"に置換すればよいのだけれども、 ラージオブジェクトが含まれているとそうはいかない。 で、検索してみるとPostgreSQLのML解決方法を発見。 まず移行元(EUC-JP)のpostgresql.confを編集。 client_encoding = UTF-8 で、設定再読み込み。 /etc/init.d/postgresql reload この状態でpg_dumpをすれば移行先で普通にpg_restoreが
PostgreSQLのバックアップ&リストア手法その1:使えば分かるPostgreSQL運用&チューニング(4)(3/3 ページ) (2)OSコマンド(rsyncなど)、バックアップツールによるバックアップ OS側で用意されているコマンドやサードパーティ製のバックアップツールを利用したバックアップ方法は、PostgreSQLを停止してデータベースクラスタをコピーすれば完了です。リストアは、データベースクラスタのディレクトリを置き換えるだけです。この方法の利点は何といっても単純明快なことですが、以下の欠点があります。 一貫性を保ったバックアップを取得するために、PostgreSQLを停止しなければならない CPUアーキテクチャが異なる環境やメジャーバージョン(先頭2けた)が異なるPostgreSQLへはリストアできない バックアップファイルのサイズが、PostgreSQLのダンプツールを使用
id: 725 所有者: msakamoto-sf 作成日: 2010-08-02 08:20:39 カテゴリ: PostgreSQL [ Prev ] [ Next ] [ 技術 ] PostgreSQLの少なくとも7.4以降では、CREATE TABLE実行時に "serial" を型に指定すると、対応するシーケンスを自動生成してnextval()してくれるようになります。 今回は、連番キー値が格納されるが主キー設定もされていないしシーケンスも使われていないカラムに対し"serial"型のような自動採番を設定する方法についてメモしておきます。 つまり、 CREATE TABLE foo (id integer, name text); これを、 CREATE TABLE foo (id serial PRIMARY KEY, name text); したことにします。 なお動作確認は
TOP > PostgreSQLエラー「createdb: データベースの生成に失敗しました: ERROR: 符号化方式 EUC_JP がロケール ja_JP.UTF-8 に合いません」の原因と解決方法 PostgreSQLエラー「createdb: データベースの生成に失敗しました: ERROR: 符号化方式 EUC_JP がロケール ja_JP.UTF-8 に合いません」の原因と解決方法 IT・コンピュータ・家電等 createdbを実行すると、 createdb: データベースの生成に失敗しました: ERROR: 符号化方式 EUC_JP がロケール ja_JP.UTF-8 に合いません といったエラーになることがある。 エラーメッセージから原因がほぼ分かるが、要するに、ロケールの文字コードと作成するDBの文字コードが異なるためにエラーが出ているようだ。 1)createdb失敗時の
DBを運用していると、どのテーブルが実際にどれくらいのファイルサイズなのかを知りたい場面があるかと思います。 そんな時、DBが使用している実データサイズを調べる方法を説明したいと思います。(データベース/テーブル) 今回はPostgreSQLが対象です。※9.1で確認しました。おそらく8系でも同じ方法かと思います ■ データベースの実データサイズを調べる データベースにはそれぞれoidという識別子が設定されています。 そして、実際にデータが格納されているディレクトリ名にもこのoidが付いています。 ですので、このoidが分かれば、あとは該当のディレクトリのサイズを調べることで、データベースの実データサイズが分かるのです。 oidはpg_stag_databaseという稼働統計情報から調べることができます。 # select datid,datname from pg_stat_databa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く