PostgreSQLではデータベースを作成すると、デフォルトで public スキーマが作成され、任意のユーザーがこのスキーマにオブジェクトを作成できました。 CVE-2018-1058 でpublicスキーマのこの仕様とsearch_pathを使ったトロイの木馬攻撃の脆弱性(仕様の潜在リスク)が報告されました。 この攻撃から守るために、以下のような方法が推奨されています。 public スキーマの CREATE 権限を REVOKE ユーザーごとにスキーマを割り振る search_path に public スキーマが含まれないように調整 PostgreSQL 15からは、1つ目の回避策がデフォルトで有効になり、データベースのオーナーだけがpublicスキーマにオブジェクトを作成できるようになります。 Remove PUBLIC creation permission on the pu
Google Cloudは開催中のイベント「Google I/O 2022」で、PostgreSQLフル互換の高性能な新データベースサービス「AlloyDB for PostgreSQL」のプレビューリリースを発表しました。 Google Cloudは以前からPostgreSQLのマネージドサービス「Cloud SQL for PostgreSQL」を提供しています。今回発表された「AlloyDB for PostgreSQL」は、Googleのクラウドインフラや機械学習の技術を積極的に投入し、より高性能かつミッションクリティカル向けのデータベースサービスとして構築したものです。 AWSと比較するならば、一般用途向けのデータベースサービスである「Amazon RDS」に対抗するのがGoogle Cloudの「Cloud SQL」であり、データベースをクラウドネイティブなアーキテクチャとして
はじめに SQLite3 くらい楽に扱えて、PostgreSQL みたいにネットワーク経由で使える物ないかなーなんて思ったりする事ないですか?ありますよね、あるんです。 postlite このニーズに答えてくれるのが postlite です。postlite を使うと SQLite3 で作られたデータベースファイルを、PostgreSQL の様に扱えます。 仕組みは至って簡単で、僕が開発している go-sqlite3 に PostgreSQL の通信プロトコルのガワと、仮想テーブルを使って PostgreSQL のスキーマを疑似しています。 インストール postlite は go-sqlite3 の vtable を使います。ですので、go install ではなく postlite の README.md に書かれた手順を使わなければなりません。
お知らせ 本記事をベースに新しい記事を公開しました。 PostgreSQL インデックス肥大化とインデックスコストへの影響(再モデル化) - ぱと隊長日誌 新しい記事ではインデックスコストモデルの正確性を向上させました。 新しい記事を参照いただけますと幸いです。 概要 PostgreSQL のインデックスサイズは一度大きくなると、その後小さくなるタイミングが限られています。 「[改訂新版]内部構造から学ぶPostgreSQL-設計・運用計画の鉄則」でインデックスファイルサイズが小さくなるのは以下のタイミングとしています。 DROP INDEX でインデックス自体を削除した場合 TRUNCATE TABLE でテーブル全体を空にした場合 REINDEX でインデックスを再構成した場合 [改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design p
S2JDBCを使って DBのデータ数十万件をまとめてDLしようとしたらエラーになった。 getResultList()じゃなくてiterate()使ったら結果をまとめて保持しなくなるからメモリを使わなくなるんじゃないの?と思ったけどダメ。 WicketのResourceStream系がキャッシュしてるのか自分で書いたオブジェクトを書き出す処理がミスってたのか何か使い方が間違ってたのか分からずハマった。 Eclipse Memory Analyzer でダンプを見たら、どこかでデータを全件保持している模様。 2/29 ここから追記S2JDBC+PostgreSQLだとs2jdbc.diconのfetchSizeプロパティの設定+トランザクションをきちんと開始する、で解決しそう。(とりあえずローカル環境でエラーの再現 → エラー修正の確認まではできた) PostgreSQL: http://o
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
(この記事は 地平線に行く とのマルチポストです) 本番環境でやらかしちゃった人 Advent Calendarで、このパターンのやらかしはなかったのでキーボードを叩くことにしました。 番外編のつもりでお楽しみください。 この記事が、新たな障害発生を防ぐことにつながれば幸いです。 何をやったのか ある日、ちょっとした調査のために本番データベースのデータを確認することになりました。 (個人情報が格納されているようなシステムではなかったので、必要であれば本番データベースへのアクセスが許されていました) もしメンテナンスがあればそのタイミングでやればよかったのですが、直近では特に予定はないとのことでした。そのため、システムが動いている状態のまま作業をすることにしました。 ごく単純な SELECT を実行するだけのつもりだったので、システムに影響がないと判断したためです。 その際、万が一コピペをミ
はじめに さっぶ。どうも、だーやまんです。 この記事は、本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiitaの11日目の記事です。 これは、中途半端な知識でサービスを運用していた結果、タイトル通りの大失敗をしてしまったお話です。個人開発での出来事なので、業務で起きたことかと胃薬を握られていた方はご安心ください。 語るのもすごい恥ずかしいレベルですが、戒めのために晒しておきます。 この記事を読んでほしい人 初めてインターネット上にサービスを公開しようとしている人 喋太郎の利用者様(この場をお借りして、改めてお詫び申し上げます。本当に申し訳ございませんでした。) 背景とか Discord読み上げBot 「喋太郎」にてやらかしました www.dayaman.work 利用者が約10万人 さくらのVPSにてAppサーバ2台、DBサーバ1台で運用 各サーバの死活監視
はじめに2019年10月15日、Amazonは自社サービスにおける実質的な”脱Oracle”を発表しました。75PBに及ぶデータを、傘下のAWSが提供するDatabase Service(AuroraやDynamoDB、Redshiftなど)へと移行したとの事。 この一報は、Amazonというグローバル規模のECの巨人、クラウド・プラットフォーマーのリーダーの一角が、大規模基幹システム領域におけるRDBMSのデファクト・スタンダードと決別したという点で、業界関係者に対して非常に大きなインパクトを残したものかと思います。 大人の色々な側面が垣間見えるものの、非常に難易度の移行PJであった事はを想像に難くありません。 “Oracleもいよいよ賞味期限を迎える” 果たしてそうなのか。ここで今一度、**”脱Oracle”とは何を脱する事なのか**、を考えてみます。 “脱Oracle”とは?第1は高
1,800万人が利用する『家族アルバム みてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
PostgreSQLでCSV等のファイルから、テーブルにデータを取り込む方法は、 メタコマンドの[/copy]を使用する方法と、SQLから[COPY]文を使用する方法があります。 メタコマンドの[/copy]は、コマンドを実行したホスト上のファイルを操作し、 SQLの[COPY]文は、PostgreSQLサーバ上のファイルを操作するという違いがあります。 今回は、SQLの[COPY]文を使用する際のポイントを3つ、ご紹介します。 ■ポイント1「パスの指定に注意!」 まずは、基本的な構文です。 COPY [テーブル名] FROM [ファイルの絶対パス]; ファイルの絶対パスを指定する際に気をつけなければならないのは、 バックスラッシュ(\)をエスケープする必要があるということです。 (例:C:\\Program Files\\PostgreSQL) ■ポイント2「TIMESTAMP型に注意!
DBのデータを自分で作成したプログラムで更新した時に、どうやって検証をするかという内容です。 PostgreSQLにはCOPY文でCSVに出力することが可能なので、出力したCSVを更新前後でdiffりました。 まずはDBの中身はこんな感じ。testという名前のDBに↓の様なデータを入れておきます。 test=# SELECT * FROM test_table; id | name | tel ----+-----------+------------ 1 | yamada | 012345678 2 | takahashi | 123456789 3 | suzuki | 234567890 1 | takeda | 3456789012 (4 rows)コマンドは、以下、1行だけ。 psql <DB名> -c "COPY <テーブル名> TO '<ファイル名>' CSV -------
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く