詳解 PostgreSQL[10/11対応]―現場で役立つ新機能と実践知識

第1章 PostgreSQLの今昔を知る―20年を超える歴史,リリースサイクル,環境構築

この記事を読むのに必要な時間:およそ 6.5 分

PostgreSQLのリリースフロー

リリースされたばかりのPostgreSQL 11ですが,PostgreSQLのメジャーバージョンは,9まではx.y.z(例:9.6.11)のx.yの部分を指していました。ですが10からはx.y表記(例:10.6)となり,メジャーバージョンはxを指すことになりました。

PostgreSQLのメジャーバージョンは毎年リリースされています。PostgreSQLのリリースの流れを知っておけば,次期バージョンPostgreSQL 12のキャッチアップの際にも役立つでしょう。

リリースまでの流れ

PostgreSQLは特定の企業に依存せず,コミュニティベースで開発されているにもかかわらず,統率されたリリースフローとなっています。図1のように1年間で,新しいメジャーバージョンのα版の開発から,機能確定後のβ版のテスト,リリースに向けた安定化までを行っています。

図1 PostgreSQLの開発の流れ

図1 PostgreSQLの開発の流れ

この流れの中で,PostgreSQLの開発者どうしのコミュニケーションはメーリングリストのpgsql-hackers@postgresql.orgで行われています。ここでのやりとりはすべてWebにアーカイブされており,誰でも自由に読むことができ,単独の企業や独裁者による開発ではなく,中立公正なコミュニケーションが約束されています。

PostgreSQLのソースコードはgit.postgresql.org/git/postgresql.gitで管理されており,GitHubではありません注1⁠。あなたが新機能やバグ対応のパッチを送りたい場合,パッチファイルを作成して先ほどのメーリングリストへ英文メールで連絡する必要があります。送られたパッチをコミュニティでチェックするしくみがCommit Festです。Commit Festの詳細は次項で説明しますが,Commit Festを乗り越えたパッチは無事に本体に取り込まれます。この流れを数度繰り返し,1年の周期でメジャーバージョンアップします。

注1)
GitHubに公式アカウントのミラーリポジトリがあるのですが,あくまでミラーリポジトリであり,Pull Requestを送っても対応されません。

Commit Festによるレビュー

Commit Festとは,集中的にパッチのレビューを行い,コードツリーにパッチを適用してコミットしていく期間およびプロセスのことを言います。端的に言えば「みんなでパッチをレビューしましょう」というしくみです。

Commit Festは,α版が出る前まで2ヵ月ごとのサイクルで行われます。Commit Festでは,1ヵ月かけてパッチを登録し,もう1ヵ月で登録されたパッチをレビューします。

Commit Festには次のメリットがあります。

  • 作成したパッチが放置されない
  • 一定の品質を保ちつつ,コードを取り込める

これにより,PostgreSQLのコードを高い品質に保ちながら,毎年のメジャーバージョンアップを可能にしているのです。

Commit Festは誰でも気軽に参加できます。興味がある人は,@sawada_masahikoさんのQiitaの記事PostgreSQLコミュニティへのパッチの投げ方」をご覧ください。正しく動作するか境界テストをしたり,大きなテストデータで確認したり,typoがないかコードレビューしたりするだけでもすばらしい貢献です。コードを書く以外にもコミュニティに貢献できる場所の一つですし,誰よりも先に新機能をキャッチアップできる場所です。みなさんぜひ,Commit Festを覗いてみましょう。

コマンドによるインストール

そろそろ実際にPostgreSQLを試したくなってきたことでしょう。本節からは,最新版のPostgreSQL 11をインストールする方法を紹介します。

PostgreSQLのインストール方法はいろいろあります。コンテナを立ち上げてCLICommand Line Interfaceからインストールすることもできますし,macOS,Windowsのインストーラを使ってGUIGraphical User Interfaceでインストールすることもできます。また,クラウドサービスがセットアップ不要のDatabase as a Serviceとして提供しています。今回紹介する方法やクラウドサービスなど,ご自身の環境に合わせてお選びください。

本特集の以降では,PostgreSQL自体を指すときは「データベース」と表記し,CREATE DATABASEで作成されるデータベースは「DB」と表記します。

本節では,CLIを利用したインストール方法を解説します。本番で使うOSはLinuxであることが多いでしょう。ここでは本番でよく使われるLinuxディストリビューションであるCentOS 7での方法を紹介します。

PostgreSQLのインストール

# yum localinstall https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-centos11-11-2.noarch.rpm
# yum install postgresql11-server \
postgresql11-contrib \
ostgresql11-devel \
postgresql11-libs

postgresユーザーで実行する

# su postgres

PostgreSQLのセットアップ

$ /usr/pgsql-11/bin/initdb -E UTF-8 \
--no-locale -D /var/lib/pgsql/11/data
$ exit
# systemctl start postgresql-11.service

バージョンの確認

# psql -V
psql (PostgreSQL) 11

以上で完了です。CLIでのインストールはWeb上に多くのHow Toが公開されていますので,特に迷うことなく行えるのではないでしょうか。

ただし,PostgreSQLをインストールする際には次の注意点があります。

  • ロケールの設定
  • 文字エンコーディングの指定
  • アクセス制限の指定

以降で順に説明します。

ロケールの設定

PostgreSQLはinitdbの際にロケールを指定しない場合,OS側に設定されているロケールを使用します。この場合の多くは,ja_JP.UTF-8が選ばれるでしょう。これに伴いDBが壊れることはありませんし,エラーなどもありません。ただし,ソート関連に影響し,OSに依存してしまうことから,意図しない挙動をすることがあります。

それを防ぐためにPostgreSQLでは一般的に,ロケールとして明示的にCを指定します。これにより,OSに依存することなく,バイナリ値を基準にした一定のソートが行われ,ORDER BYの性能も向上します。

ロケールにCを指定するには,前述の手順のとおり--no-localeを指定するか,--locale=Cを指定します。--no-locale--locale=Cは同義ですのでどちらでもかまいません。

もし指定し忘れた場合,基本的にはDBを作りなおすことになるため,無停止では変更できないと思ってください。運用が走り出すと変更がしにくい箇所ですので,最初の構築が重要です。

文字エンコーディングの設定

続いてエンコーディングの指定です。

initdbで明示的に指定しなかった場合のデフォルトではsql_asciiになります。sql_asciiではターミナルでマルチバイト文字を入力できず,たいへん苦労しますので,前述の手順のとおり明示的に-E UTF-8を指定するようにしましょう。

DB作成時のロケールとエンコーディングの指定

万が一,initdbの際にロケールとエンコーディングを指定し忘れた場合は,次の方法で対応できます。

DBの作成時に指定する例

postgres=# CREATE DATABASE DB名 \
LC_COLLATE 'C' LC_CTYPE 'C' \
ENCODING 'UTF8' TEMPLATE template0;

この方法は,initdbできない場合,たとえばAmazon RDSRelational Database Serviceなどで利用する際に必要です。

アクセス制限の設定

PostgreSQLは,pg_hba.confによってアクセス制限を行います。デフォルトではlocalhost以外のアクセスは無効になっていますので,自分の環境に合わせたネットワークを指定します。

その際,注意点が2つあります。

  • trustは指定しない
  • 0.0.0.0/0は指定しない

trustはパスワード認証をしない設定です。スーパーユーザーであるpostgresなどにノンパスワードでアクセスできるためたいへん危険です。0.0.0.0/0はすべてのIPアドレスからアクセスできます。

ときどきWebの記事などで上記の設定を指定しているHow Toがありますので注意してください。もし外部からアクセスできる場所のサーバで0.0.0.0/0 trustで設定すると,悪意のあるユーザーは不正アクセスし放題となります。RDBMSは個人情報など重要なデータを保存することが多いので,正しくアクセス制限して不正アクセスから守りましょう。

設定方法は,たとえば192.169.1.0/24のネットワークからのみパスワード認証でアクセスさせたい場合,次のとおりになります。

# TYPE DATABASE USER ADDRESS        METHOD
host   all      all  192.169.1.0/24 md5
アクセス制限の解除

PostgreSQLのアクセス制限には,設定箇所が2つあるというハマりどころがあります。もう一つのファイルはpostgresql.confです。postgresql.confは,アクセス制限に限らず,PostgreSQLの全体に関わる設定をするところです。たとえばwork_memやshared_buffersの値を指定できます。

postgresql.confも,デフォルトではlocalhost以外のアクセスは無効になっています。pg_hba.confだけ変更しても,postgresql.confを変更していない場合は外部からアクセスできませんので注意してください。localhost以外からアクセスさせたい場合,次のように修正する必要があります。

変更前

listen_addresses = 'localhost'

変更後

listen_addresses = '*'

postgresql.confpg_hba.confは,PostgreSQLサーバの設定リロードまたは再起動するまで反映されません。両ファイルを変更しても,適切に読み込んでいないため不適切な設定のまま運用される可能性がありますので,必ず再読み込みしましょう。

ここまで設定すればPostgreSQLにアクセスできるはずです。接続方法については後述します。

著者プロフィール

曽根壮大(そねたけとも)

株式会社オミカレ副社長兼CTO。数々の業務システム,Webサービスなどの開発・運用を担当し,2017年に株式会社はてなでサービス監視サービス「Mackerel」のCRE(Customer Reliability Engineer)を経て現職。 コミュニティでは,Microsoft MVPをはじめ,日本PostgreSQLユーザ会の理事として勉強会の開催を担当し,各地で登壇している。 builderscon 2017,YAPC::Kansaiなどのイベントでベストスピーカーを受賞し,分かりやすく実践的な内容のトークに定評がある。 他に,岡山Python勉強会を主催し,オープンラボ備後にも所属。著書に『Software Design』誌で,データベースに関する連載「RDBアンチパターン」をまとめた『失敗から学ぶRDBの正しい歩き方』を執筆。

@soudai1025
はてなid:Soudai

著書