本連載では巨大な PostgreSQLドキュメントの読むべきポイントを紹介していきます。
デプロイメント編、運用管理編に引き続きまして、今回はアプリケーション開発編です。
アプリケーション開発編では、データベースサーバは既に構築されているものとして、その上でテーブル定義を記述したり、そこで動作させる SQL やユーザ定義関数（ストアドプロシージャ）を開発するために見るべきドキュメントを示します。
なお、PostgreSQLドキュメントの在り処や基本的な見方についてはデプロイメント編の冒頭に記載しています。また、これまで同様、PostgreSQL 10.x バージョンを主対象に書いています。
pg_repack は PostgreSQL のテーブルをオンラインで再編成できるツールです。本記事では pg_repackについて紹介します。
良く知られている通り、PostgreSQL は追記型アーキテクチャを採用しています。UPDATE や DELETE をしても旧データを格納した行はしばらく物理ファイル上に残り、これを VACUUM コマンドや自動 VACUUM で整理して、その領域を再利用可能にする仕組みとなっています。何らかの理由でこれらの手動・自動の VACUUM 処理が実行されなかった場合には、データ格納に使われない不要領域が増加し、性能劣化の原因となります。そのような場合には、CLUSTER コマンドや VACUUM FULL コマンドを使って、テーブルの再編成をするのですが、これらのコマンドは強いロックを取得するため、サービス中の適用が難しいという課題がありました。
pg_repack は CLUSTER または VACUUM FULL と同様に不要領域の削除や行の並び替えることができますが、処理中に強いロックをごく短時間しか取得しないため、サービス中にも実施が可能となります。
前回記事のデプロイメント編に引き続き、巨大な PostgreSQLドキュメントの読むべきポイントを紹介していきます。今回は「PostgreSQLドキュメントの歩き方 – 運用管理編」と題しまして、主として構築済みの PostgreSQL の運用管理を担当する人を対象とします。
PostgreSQLドキュメントの在り処や基本的な見方については前回記事を参照ください。
PostgreSQLには A4サイズに印刷して 4000ページほどになる巨大なドキュメントが付属しています。さらに、日本PostgreSQLユーザ会の有志により、日本語訳版も作られています。PostgreSQLの機能についてはこのドキュメントで網羅していますが、機能の充実によって内容が膨れ上がり、知りたいことを探すのにどこから手を付けようか悩むことも少なくないでしょう。
そこで本稿では「PostgreSQL ドキュメントの歩き方」として、 PostgreSQL入門者むけに遠大なドキュメントに立ち向かうヒントを提供します。今回は、デプロイメント編として PostgreSQL を導入する場面を想定し、有益な情報が見つけられるドキュメントページをご紹介します。
SRA OSS は PostgreSQL 関連サービスを提供しているだけではなく、PostgreSQL の開発にも参加しています。過去には再帰SQLの実装や、ラージオブジェクトの64bit化などを行ってきました。
そして、最近は Incremental View Maintenance という機能の実装を提案することを検討しています（2018年12月末にPostgreSQL開発MLにて議論開始）。これはマテリアライズドビューの更新を高速に行うための技術です。PostgreSQLが大規模システムの採用が増加する中、マテリアライズドビューの利用は増えていると考えており、またその高速リフレッシュは喫緊の課題であると考えています。
これに関する発表を昨年の10月にポルトガルのリスボンで開催された PostgreSQL Conference Europe (PGConf.EU) 2018 で発表してきました（レポートはこちら）。本記事では、その内容について解説します。
Barman とは PostgreSQL のPITR（ポイントインタイムリカバリ）を簡単に管理してくれるツールです。
PITRとはバックアップ／リストア方式の一つで、過去の指定した時点の状態に復元することが可能です。PITRは、データベースクラスタの物理コピー（ベースバックアップと呼びます）を取得し、以降のデータ変更が書き出される WALファイルを継続的に保存する（保存したものをWALアーカイブやアーカイブログと呼びます）ことで実現されます。現在稼働しているデータベースクラスタを障害やオペレーションミスから復旧したい場合には、保存していたベースバックアップにWALアーカイブを適用することで、ベースバックアップ取得時点からWALアーカイブが適用できる限りの任意の時点に復元することができます。
PITR は PostgreSQL のバックアップ方式としてよく用いられる手法ですが、DB 管理者が考慮すべきことや操作手順が増え、運用管理の手間が増えます。例えば、PITR の運用はベースバックアップの世代管理や、溜まり続ける古いアーカイブログファイルの削除は PostgreSQL の本体機能として備わっておらず、DB 管理者がそのような処理を行うスクリプトを用意しなければなりません。バックアップからのリカバリ作業も DB 管理者が手動で煩雑な手順を実施する必要があります。
このリリースは 11.0 からの修正リリース（2018年11月8日リリース）です。
11.x からのアップデートではダンプ、リストアは不要です。
しかしながら、pg_stat_statements拡張を使っている場合は修正を適用するための操作が必要です。
以下の関連する項目を参照してください。
このリリースは 10.5 からの修正リリース（2018年11月8日リリース）です。
10.x からのアップデートではダンプ、リストアは不要です。
しかしながら、pg_stat_statements拡張を使っている場合は修正を適用するための操作が必要です。
以下の関連する項目を参照してください。
また、10.4 より前のバージョンからアップデートを行う場合は 10.4 に関する技術情報を参照してください。
このリリースは 9.6.10 からの修正リリース（2018年11月8日リリース）です。
9.6.x からのアップデートではダンプ、リストアは不要です。
しかしながら、9.6.9 より前のバージョンからアップデートを行う場合は 9.6.9 に関する技術情報を参照してください。
このリリースは 9.5.14 からの修正リリース（2018年11月8日リリース）です。
9.5.x からのアップデートではダンプ、リストアは不要です。
しかしながら、9.5.13 より前のバージョンからアップデートを行う場合は 9.5.13 に関する技術情報を参照してください。