Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
PostgreSQLで始める 
OSS開発 
日本PostgreSQLユーザ会 
花田茂 
オープンソースカンファレンス 
2014 Hiroshima 2014.09.20 
1
2 
自己紹介 
氏名:花田 茂 
メール:shigeru.hanada@gmail.com 
twitter:@s87 
ブログ:http://d.hatena.ne.jp/s87/ 
経歴: 
PostgreSQL触る前はOracle+業務...
3 
日本PostgreSQLユーザ会について 
• PostgreSQLの普及促進を目的に活動する特定非営利活 
動法人(NPO)です。 
• http://postgresql.jp/ 
• 略称は「JPUG」 
• 北は北海道から南は沖縄...
4 
はじめに 
みなさん 
PostgreSQL 
使ってますか?
5 
はじめに 
• VACUUMすると止まるんでしょ? 
• 検索とか、MySQLの方が速いし… 
• レプリケーションできるの? 
• DB使ってないんで!(うらやましいw) 
• Etc.
6 
はじめに 
今日お話しするのは、そういった 
「PostgreSQLを実際に 
使うに当たって絶対に 
知っておくべきこと」 
ではありません! 
日々の実務的な話は、 
明日(9/21)の 
中国地方DB勉強会で…
7 
はじめに 
データベースって、所詮道具ですから 
–速い 
–安い 
–美味い(ビジネス的に) 
ならいいわけです
8 
はじめに 
というわけで、今日のお話は「データベー 
スを選ぶときの基準に 
開発し易い 
いろんな意味で 
を入れてみませんか?」というご提案です
PostgreSQLには、いくつかの 
機能拡張の仕組みがあります 
PostgreSQLに含まれる同種のもの 
9 
PostgreSQLの拡張性 
PostgreSQLに備わった機能拡張の仕組み 
概要 
関数SQLから呼び出す関数を追加d...
10 
関数/集約 
特徴 
SQL文で事前に定義した処理を利用可能 
標準でC言語、SQL、PL/pgSQL、Tcl、Perl、Python等をサポート 
CREATE FUNCTION文でカタログに登録 
配列を含むSQLデータ型が利用可能...
11 
演算子 
特徴 
SQL文で使える演算子を追加可能 
内部的には関数のシンタックスシュガー 
事前に定義した関数をCREATE OPERATOR文で演算子に割り当て 
被演算データ型でのオーバーロードも可能 
COMUTATOR、NAG...
12 
データ型 
特徴 
ビジネスオブジェクトを表すデータ型を追加可能 
新しいデータ型を処理する関数群を事前に定義 
CREATE TYPE文でカタログに登録 
データ型に応じた演算子を定義するとより便利に 
使用例 
•ksj 
•そのま...
13 
インデックス 
特徴 
B-TreeやGIN、GiSTとは別にインデックスを追加可能 
インデックス用の関数や演算子クラスを定義した後、pg_amに行を追加 
CREATE INDEX文のUSING句に新しいインデックスを指定 
Pos...
14 
手続き言語 
特徴 
PL/pgSQLやPL/Perlのような手続き言語を追加可能 
処理に向いた言語で関数を実装できるようになる 
ハンドラ関数を定義してからCREATE LANGUAGE文でカタログに登録 
言語処理系の理解が必要で...
15 
フック関数 
特徴 
PostgreSQLの内部処理に直接手を入れることが可能(特定箇所のみ) 
C言語で関数を記述し、フック関数として登録 
プランナやエグゼキュータの処理をカスタマイズできる 
PostgreSQLの内部処理の理解が...
16 
外部データラッパ 
特徴 
外部データをDMLで操作可能(9.3から更新もOK) 
C言語でハンドラ関数やオプション検証関数を記述 
基本的には列ごとの文字列データが取得できれば対応可能 
展示ブースで 
デモ 
やってます! 
WHE...
エクステンション 
関数やその他のオブジェクトがバラバラにあると 
17 
管理しづらいので… 
EXTENSIONでパッケージ化しましょう 
EXTENSIONとは? 
•複数のオブジェクトを統合して管理 
•アンインストール用のSQLスクリ...
18 
既存の拡張モジュールは… 
いくつかのサイトで公開/配布されています 
pgFoundry 
SourceForge/ 
github/ 
Google Code 
PGXN 
古くから運営されている公式(?)のプロジェ 
クトホスティ...
19 
ピッタリくるのがなければ 
• フォークした製品から 
探してみましょう 
現在もアクティブにメンテナンス 
されているものだけでも19製品! 
– https://wiki.postgresql.org/wiki/PostgreSQL...
20 
ピッタリくるのがなければ 
• 分析系 
– Pivotal Greenplum Database(Pivotal) 
– Netteza(IBM) 
– Postgres XL 
• DWH 
– Vertica(HP) 
– Red...
21 
それでも足りない! 
• ならば、作りましょう!
22 
PostgreSQLの進化 
• 9.4の主な変更点 
– 論理ログ出力 
• 【Andres Freund】 
– 動的バックグラウンドワーカー 
• 【Robert Haas】 
– 共有メモリセグメントの動的確保 
• 【Robe...
23 
PostgreSQLの進化(3) 
• PostgreSQLはオープンソースソフトウェア 
• コミュニティが著作権を持つ 
• 一定の条件を満たせば誰でも開発に参加可能!
24 
PostgreSQLの進化(4) 
• 例:View関連のリリースノート
25 
PostgreSQLの進化(5) 
• 例:View関連のリリースノート 
機能追加のクレジットは個人名 
所属企業やスポンサー企業の名前は 
メーリングリストでの言及のみOK
26 
PostgreSQL開発の流れ(1) 
• メジャーリリースは一年に一度 
– 一ヶ月ごとに開発→マージのサイクルを繰り返します 
– マージ期間を「CommitFest」と呼びます 
• 9.5の開発スケジュール 
– 2014年 
...
27 
PostgreSQL開発の流れ(2) 
• Developer Meeting 
–主要な開発者が集まって、F2Fで議論 
• 次バージョンで開発したい内容の提案 
• 開発の進め方の議論 
–オタワで開催されるPGconと同時期に開催...
28 
PostgreSQL開発の流れ(3) 
• CommitFest(コミットフェスト) 
–過去の苦い経験から生まれた、新機能取り込み 
のサイクル 
• 以前は、パッチを投稿してもレビューしてもらえず 
埋もれていった機能も 
• 機能...
29 
PostgreSQL開発の流れ(4) 
• CommitFestアプリ 
– 投稿されたパッチは、専用Webアプリで管理 
• https://commitfest.postgresql.org 
• 利用にはPostgreSQLコミュ...
30 
PostgreSQL開発の流れ(5) 
• CommitFestの状態 
– Future 
• 将来開催予定 
– Open 
• パッチ登録受付中 
– In Progress 
• 現在進行中 
– Closed 
• 終了
31 
PostgreSQL開発の流れ(6) 
• CommitFestでのパッチ管理 
– パッチは、Webベースの専用アプリで管理 
• https://commitfest.postgresql.org 
• PostgreSQLコミュニ...
32 
PostgreSQL開発の流れ(7) 
• CommitFestでのパッチ状態 
– Needs Review 
• 開発者がパッチを投げてレビュー待ち 
– Waiting on Author 
• レビューコメントが付いて開発者対応...
33 
PostgreSQL開発の流れ(8) 
• CommitFestでのレビュー 
– レビューの仕方は日本語ドキュメントで! 
• http://wiki.postgresql.org/wiki/Reviewing_a_Patch/ja ...
34 
PostgreSQL開発の流れ(9) 
• レビューは開発参加の第一歩! 
– パッチを提案する人は必ず他者のパッチをレビューす 
る決まり 
• つまり、レビューできないとパッチが投げられない! 
– いきなり全体を把握するのは困難(...
35 
パッチレビュー(1) 
• 何をレビューすればいいの? 
–提案レビュー 
• パッチフォーマット 
• パッチ適用可否 
• ドキュメントやテストの充足 
–仕様レビュー 
• パッチの目的適合性、必要性、重複度 
• SQL標準への...
36 
パッチレビュー(2) 
• 何をレビューすればいいの? 
–機能レビュー 
• 公言している機能の実現度 
• コーナーケース(重箱の隅)の完成度 
• アサーション違反やクラッシュケースの確認 
–性能試験 
• 性能低下を招かないこ...
37 
パッチレビュー(3) 
• 何をレビューすればいいの? 
– コーティングレビュー 
• コーディング規約の準拠 
– http://wiki.postgresql.org/wiki/Developer_FAQ#What.27s_the...
38 
パッチレビュー(4) 
• レビューしたいけど環境がない! 
–レビューワーはVMが無料で借りられます! 
As part of an ongoing effort to encourage patch review for the 
...
39 
パッチレビュー(5) 
• レビューしたいけど環境がない! 
– VMでCentOS入れとけば十分です! 
• Windowsでのビルドはちょっと手間がかかるので 
、Linux環境がお勧め 
– 一応マニュアルにやり方載ってます 
•...
40 
開発環境の用意(1) 
• 開発環境に必要なもの 
– OS 
• Unix、Linux、Mac OS Xなど 
–ツール 
• gccなどのCコンパイラ 
• bison/fex/perl 
• DocBook(ドキュメントコンパイル...
41 
開発環境の用意(2) 
• ソース持ってきましょう 
– gitで開発リポジトリをクローン 
• git://git.postgresql.org/git/postgresql.git 
• 全versionの変更履歴が手元に届きます ...
42 
開発環境の用意(3) 
• パッチ当てる場合は、ブランチに注意 
– 次バージョンはmasterブランチで開発 
• 過去バージョンはREL9_3_STABLEなどのブランチ 
[postgresql(master)]$ git bra...
43 
開発環境の用意(4) 
• ソースコードの構成 
[postgresql(master)]$ ls -F | cat 
COPYRIGHT 著作権表記 
GNUmakefile.in Makefile生成元 
Makefile Make...
44 
開発環境の用意(5) 
• ソースコードの構成(src) 
[postgresql(master)]$ ls -F src/* | cat 
backend/ 
bin/ 
common/ 
include/ 
interfaces/ ...
45 
開発環境の用意(6) 
• ソースコードの構成(src/backendの一部) 
[postgresql(master)]$ ls -F src/backend/* | cat 
access/ 
bootstrap/ 
catalog...
46 
開発環境の用意(7) 
• PostgreSQLの処理の流れ 
– クライアントがクエリ実行 
– バックエンド(postgres)がメッセージを受け付ける 
– パーサがクエリ文字列を解析し構文木を生成 
• 解析の過程でカタログを参...
47 
PostgreSQLのビルド 
• いつも通りの3ステップです 
– confgure、make、make install 
• ただし、レビュー・開発用には少し工夫を 
– --enable-cassert 
• Assert()マク...
48 
ソース読んでみましょう(1) 
• とりあえず、もう一工夫 
–タグファイルを作成してタグジャンプしましょ 
う• 
src/tools/make_ctags 
• src/tools/make_etags 
• さて、どこから読みまし...
49 
ソース読んでみましょう(2) 
• まずはエグゼキュータやSQLコマンドあた 
りがお手頃 
– SELECTってどう動くの? 
– VACUUMって結局何やってるの? 
– EXPLAINのJSONフォーマットってどう実現し 
ている...
50 
動きを見てみましょう 
• gdbを使って処理を追ってみましょう 
– psqlで接続 
– pg_backend_pid()でバックエンドプロセス特定 
– gdbでアタッチ 
– 適当なところにブレークポイント設定 
• exec_...
51 
改造してみましょう(1) 
• ソースコードは書き換え放題! 
– オープンソースですから。 
– gitでブランチ切っておくと幸せになれます 
• いつでも戻せる、差分が分かる、Etc. 
– ソース書き換えたら、新しいバイナリに切り...
52 
改造してみましょう(2) 
• デバッグ時のTips 
– elog()でのprintfデバッグ 
• プロトタイプ:elog(level, fmt, ...) 
• 例: 
int 
func(int param) 
{ 
int f...
53 
改造してみましょう(3) 
• デバッグ時のTips 
– NodeTag 
• NodeTagオブジェクト種別識別子 
• 構造体の先頭にNodeTagを置き、その値でオブ 
ジェクト種別を識別 
/* 
* The first fi...
54 
改造してみましょう(4) 
– NodeTag(続き) 
typedef struct JoinExpr 
{ 
NodeTag type; 
JoinType jointype; /* type of join */ 
bool is...
55 
提案してみましょう(1) 
• どんなネタで? 
– バグを修正(CF外で提案可能) 
• pgsql-bugsにもネタあり 
– 欲しい機能を実現 
• pgsql-generalにもネタあり 
– 遅い部分を改善 
• pgsql-...
56 
提案してみましょう(2) 
• 提案のステップ 
– pgsql-hackersに外部仕様等を提案 
– 意見がまとまってきたらPoCパッチを作成したり 
– コンセンサスが得られたらCommitFestに登録 
– CommitFes...
57 
提案してみましょう(3) 
• 提案のポイント 
– 実装の前に設計 
• いきなり実装せず、設計を議論(将来性・拡張性を重視) 
• 最初は難しいので、否定されてもくじけずにチャレンジを! 
– 意見がまとまってきたらPoCパッチ 
...
58 
開発関連の情報源 
• Development Information(PostgreSQL wiki) 
– 開発者向け情報 
– http://wiki.postgresql.org/wiki/Development_informa...
59 
PostgreSQLの情報源 
• 日本PostgreSQLユーザ会 
– 日本でのPostgreSQLの普及等 
– 勉強会も年4回程度開催(Ustream中継あり) 
– http://www.postgresql.jp 
• Le...
60 
おわりに 
• ご清聴ありがとうございました。
Upcoming SlideShare
Loading in …5
×

PostgreSQLではじめるOSS開発@OSC 2014 Hiroshima

1,894 views

Published on

2014.09.20のオープンソースカンファレンス 2014 Hiroshimaの講演資料です。

Published in: Technology
  • Be the first to comment

PostgreSQLではじめるOSS開発@OSC 2014 Hiroshima

  1. 1. PostgreSQLで始める OSS開発 日本PostgreSQLユーザ会 花田茂 オープンソースカンファレンス 2014 Hiroshima 2014.09.20 1
  2. 2. 2 自己紹介 氏名:花田 茂 メール:shigeru.hanada@gmail.com twitter:@s87 ブログ:http://d.hatena.ne.jp/s87/ 経歴: PostgreSQL触る前はOracle+業務アプリ開発 PostgreSQLの検証や周辺ツールの開発 PostgreSQL本体開発(外部テーブルサポートなど) pgCon2012開発者会議@Ottawa参加
  3. 3. 3 日本PostgreSQLユーザ会について • PostgreSQLの普及促進を目的に活動する特定非営利活 動法人(NPO)です。 • http://postgresql.jp/ • 略称は「JPUG」 • 北は北海道から南は沖縄まで9つの支部があり、それぞ れが特徴を出した活動をしています。 – 勉強会やOSCへの出展/講演等 • いくつかの分科会活動があり、ドキュメントの充実や技 術検証等を行っています。 – 仕組み分科会、文書・書籍関連分科会など
  4. 4. 4 はじめに みなさん PostgreSQL 使ってますか?
  5. 5. 5 はじめに • VACUUMすると止まるんでしょ? • 検索とか、MySQLの方が速いし… • レプリケーションできるの? • DB使ってないんで!(うらやましいw) • Etc.
  6. 6. 6 はじめに 今日お話しするのは、そういった 「PostgreSQLを実際に 使うに当たって絶対に 知っておくべきこと」 ではありません! 日々の実務的な話は、 明日(9/21)の 中国地方DB勉強会で…
  7. 7. 7 はじめに データベースって、所詮道具ですから –速い –安い –美味い(ビジネス的に) ならいいわけです
  8. 8. 8 はじめに というわけで、今日のお話は「データベー スを選ぶときの基準に 開発し易い いろんな意味で を入れてみませんか?」というご提案です
  9. 9. PostgreSQLには、いくつかの 機能拡張の仕組みがあります PostgreSQLに含まれる同種のもの 9 PostgreSQLの拡張性 PostgreSQLに備わった機能拡張の仕組み 概要 関数SQLから呼び出す関数を追加dblink()、など 集約集約関数を追加max()、sum()、count()など 演算子データ型に応じた演算子を追加幾何演算など データ型独自データ型を追加IPアドレス、幾何図形、JSONなど インデックス特性に合ったインデックスを追加B-Tree、GIN、GiSTなど 手続き言語関数を実装する新しい言語を追加PPLL//PPeerrll、PPLL//ppggSSQQLLなど フック関数PostgreSQLの処理を差し替えauto_explainなど 外部データラッパ外部データを通常の表と同様に検索postgres_fdw、oracle_fdwなど
  10. 10. 10 関数/集約 特徴 SQL文で事前に定義した処理を利用可能 標準でC言語、SQL、PL/pgSQL、Tcl、Perl、Python等をサポート CREATE FUNCTION文でカタログに登録 配列を含むSQLデータ型が利用可能で、戻り値は複数列/複数行も可 ユーザ定義の集約関数も追加可能 トランザクションは制御できない 使用例 •Orafce •Oracleの標準関数をPostgreSQLに移植したもの •PGXNで配布(http://pgxn.org/dist/orafce/) •json_accessors •JSON型へのアクセスを容易にする関数群 •PGXNで配布(http://pgxn.org/dist/json_accessors/)
  11. 11. 11 演算子 特徴 SQL文で使える演算子を追加可能 内部的には関数のシンタックスシュガー 事前に定義した関数をCREATE OPERATOR文で演算子に割り当て 被演算データ型でのオーバーロードも可能 COMUTATOR、NAGATOR、MERGEなどの最適化オプション指定可能 使用例 •parray_gin •文字列配列の部分一致検索をサポートする演算子を提供 •PGXNで配布(http://pgxn.org/dist/parray_gin/)
  12. 12. 12 データ型 特徴 ビジネスオブジェクトを表すデータ型を追加可能 新しいデータ型を処理する関数群を事前に定義 CREATE TYPE文でカタログに登録 データ型に応じた演算子を定義するとより便利に 使用例 •ksj •そのまま演算可能な漢数字型(例: 五百拾六 + 二百参 → 七百拾九) •githubで公開(https://github.com/nuko-yokohama/ksj)
  13. 13. 13 インデックス 特徴 B-TreeやGIN、GiSTとは別にインデックスを追加可能 インデックス用の関数や演算子クラスを定義した後、pg_amに行を追加 CREATE INDEX文のUSING句に新しいインデックスを指定 PostgreSQLのインデックス機構の把握が必要でハードルは高め 使用例 •textsearch_ja •sennaやgroongaをエンジンに使った日本語全文検索機能を提供 •pgFoundryで配布(http://textsearch-ja.projects.pgfoundry.org/)
  14. 14. 14 手続き言語 特徴 PL/pgSQLやPL/Perlのような手続き言語を追加可能 処理に向いた言語で関数を実装できるようになる ハンドラ関数を定義してからCREATE LANGUAGE文でカタログに登録 言語処理系の理解が必要でハードルは高め 使用例 •PL/v8 •JavaScriptで関数を記述できる •Google Codeで配布(http://code.google.com/p/plv8js/)
  15. 15. 15 フック関数 特徴 PostgreSQLの内部処理に直接手を入れることが可能(特定箇所のみ) C言語で関数を記述し、フック関数として登録 プランナやエグゼキュータの処理をカスタマイズできる PostgreSQLの内部処理の理解が必要でハードルはかなり高め 使用例 •pg_statsinfo •各種SQLコマンドの実行をフックし追加の性能情報を自動的に取得 •pgFoundryで配布(http://pgstatsinfo.projects.pgfoundry.org/)
  16. 16. 16 外部データラッパ 特徴 外部データをDMLで操作可能(9.3から更新もOK) C言語でハンドラ関数やオプション検証関数を記述 基本的には列ごとの文字列データが取得できれば対応可能 展示ブースで デモ やってます! WHERE句の条件をリモートに渡すことも可能 ソート済みの結果が得られるならば、ローカルでのソートを省略可能 使用例 •mongo_fdw •Mongo DBの内容をPostgreSQLへのSELECT文で取得可能 •PGXNで配布(http://pgxn.org/dist/mongo_fdw/) •oracle_fdw •Oracleの持つデータをDMLで操作 •GitHubで配布(http://laurenz.github.io/oracle_fdw/)
  17. 17. エクステンション 関数やその他のオブジェクトがバラバラにあると 17 管理しづらいので… EXTENSIONでパッケージ化しましょう EXTENSIONとは? •複数のオブジェクトを統合して管理 •アンインストール用のSQLスクリプトは不要 • pg_dumpによる移行やアップグレードもサポート •同梱追加モジュールはほとんどがEXTENSION • OraleのPACKAGEとはちょっと違う…
  18. 18. 18 既存の拡張モジュールは… いくつかのサイトで公開/配布されています pgFoundry SourceForge/ github/ Google Code PGXN 古くから運営されている公式(?)のプロジェ クトホスティングサイト http://pgfoundry.org/ 一般のプロジェクトホスティングサイト http://sourceforge.org/、http://github.com/ http://code.google.com/ EXTENSIONを配布するサイトで、CPANライ クなコマンドpgxnclientでインストール可能 http://pgxn.org/
  19. 19. 19 ピッタリくるのがなければ • フォークした製品から 探してみましょう 現在もアクティブにメンテナンス されているものだけでも19製品! – https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases
  20. 20. 20 ピッタリくるのがなければ • 分析系 – Pivotal Greenplum Database(Pivotal) – Netteza(IBM) – Postgres XL • DWH – Vertica(HP) – Red Shift(Amazon) • RAC対抗? – Postgres XC • Oracle互換 – Postgres Plus Advanced Server(EnterpriseDB)
  21. 21. 21 それでも足りない! • ならば、作りましょう!
  22. 22. 22 PostgreSQLの進化 • 9.4の主な変更点 – 論理ログ出力 • 【Andres Freund】 – 動的バックグラウンドワーカー • 【Robert Haas】 – 共有メモリセグメントの動的確保 • 【Robert Haas, Amit Kapila】 – マテリアライズドビュー更新のロックレベル低減 • 【Kevin Grittner】 – 構造化(非テキスト)JSONデータ型(JSONB)の追加 • 【Oleg Bartunov, Teodor Sigaev, Alexander Korotkov, Peter Geoghegan, and Andrew Dunstan】 – ALTER SYSTEM SQLコマンドによる設定ファイル編集 • 【Amit Kapila】 – いくつかのALTER TABLEコマンドのロックレベル低減 • 【Simon Riggs, Noah Misch, Robert Haas】
  23. 23. 23 PostgreSQLの進化(3) • PostgreSQLはオープンソースソフトウェア • コミュニティが著作権を持つ • 一定の条件を満たせば誰でも開発に参加可能!
  24. 24. 24 PostgreSQLの進化(4) • 例:View関連のリリースノート
  25. 25. 25 PostgreSQLの進化(5) • 例:View関連のリリースノート 機能追加のクレジットは個人名 所属企業やスポンサー企業の名前は メーリングリストでの言及のみOK
  26. 26. 26 PostgreSQL開発の流れ(1) • メジャーリリースは一年に一度 – 一ヶ月ごとに開発→マージのサイクルを繰り返します – マージ期間を「CommitFest」と呼びます • 9.5の開発スケジュール – 2014年 • Developer Meeting(5月) • CommitFest(6月、8月、10月、12月) – 2015年 • CommitFest(2月) • βテスト(5月〜?) • 正式リリース(9月?)
  27. 27. 27 PostgreSQL開発の流れ(2) • Developer Meeting –主要な開発者が集まって、F2Fで議論 • 次バージョンで開発したい内容の提案 • 開発の進め方の議論 –オタワで開催されるPGconと同時期に開催 • Developer Meeting以外にもCluster Summit等も –議論の内容はwikiで公開 • http://wiki.postgresql.org/wiki/PgCon_2014_D eveloper_Meeting
  28. 28. 28 PostgreSQL開発の流れ(3) • CommitFest(コミットフェスト) –過去の苦い経験から生まれた、新機能取り込み のサイクル • 以前は、パッチを投稿してもレビューしてもらえず 埋もれていった機能も • 機能開発期間とレビュー・取り込み期間を明確にし て、開発リソースを効率よく活用するための仕組み • 詳細情報はPostgreSQL Wikiにて – http://wiki.postgresql.org/wiki/CommitFest –最近はCommitFest Managerという進行役が いて、レビュー状況などを管理
  29. 29. 29 PostgreSQL開発の流れ(4) • CommitFestアプリ – 投稿されたパッチは、専用Webアプリで管理 • https://commitfest.postgresql.org • 利用にはPostgreSQLコミュニティアカウントが必要 – https://www.postgresql.org/account/signup/
  30. 30. 30 PostgreSQL開発の流れ(5) • CommitFestの状態 – Future • 将来開催予定 – Open • パッチ登録受付中 – In Progress • 現在進行中 – Closed • 終了
  31. 31. 31 PostgreSQL開発の流れ(6) • CommitFestでのパッチ管理 – パッチは、Webベースの専用アプリで管理 • https://commitfest.postgresql.org • PostgreSQLコミュニティアカウントが必要 – パッチを作成したら、pgsql-hackers MLに投稿し、 そのメールのMessage-IDを「Open」状態の CommitFestに登録 – CommitFestが始まると、レビュワーがついてパッチ をレビューしてくれるので、開発者はレビューコメン トに対応
  32. 32. 32 PostgreSQL開発の流れ(7) • CommitFestでのパッチ状態 – Needs Review • 開発者がパッチを投げてレビュー待ち – Waiting on Author • レビューコメントが付いて開発者対応待ち – Ready for Committer • レビューワーがOKを出してコミッタの判断待ち – Committed • 晴れてコミット! – Returned with Feedback • 本CFではこれ以上扱わない、次回以降に再挑戦
  33. 33. 33 PostgreSQL開発の流れ(8) • CommitFestでのレビュー – レビューの仕方は日本語ドキュメントで! • http://wiki.postgresql.org/wiki/Reviewing_a_Patch/ja – 永安さんのブログにも整理されています! • http://pgsqldeepdive.blogspot.jp/2013/06/commitfestp atchreview.html – Round Robin Reviewerという制度も! • 比較的簡単なパッチをCF Managerが割り当ててくれます
  34. 34. 34 PostgreSQL開発の流れ(9) • レビューは開発参加の第一歩! – パッチを提案する人は必ず他者のパッチをレビューす る決まり • つまり、レビューできないとパッチが投げられない! – いきなり全体を把握するのは困難(というか無理)な ので、簡単なパッチのレビューをとっかかりにするの は効果的! – 正式にレビュワーとして登録しなくても、他者のレ ビュー結果を自分のものと比べると勉強になります!
  35. 35. 35 パッチレビュー(1) • 何をレビューすればいいの? –提案レビュー • パッチフォーマット • パッチ適用可否 • ドキュメントやテストの充足 –仕様レビュー • パッチの目的適合性、必要性、重複度 • SQL標準への準拠 • 他の箇所との整合性
  36. 36. 36 パッチレビュー(2) • 何をレビューすればいいの? –機能レビュー • 公言している機能の実現度 • コーナーケース(重箱の隅)の完成度 • アサーション違反やクラッシュケースの確認 –性能試験 • 性能低下を招かないこと • 性能向上パッチの場合の性能改善度
  37. 37. 37 パッチレビュー(3) • 何をレビューすればいいの? – コーティングレビュー • コーディング規約の準拠 – http://wiki.postgresql.org/wiki/Developer_FAQ#What.27s_the_formatti ng_style_used_in_PostgreSQL_source_code.3F • 移植性や多環境での動作確認 • コードと整合した適切なコメント • セキュリティ上の考慮 – アーキテクチャレビュー • アーキテクチャ・他の機能・モジュールとの整合性 • 将来的に問題となる依存性などがないか – レビューのレビュー • レビューが適切になされたか
  38. 38. 38 パッチレビュー(4) • レビューしたいけど環境がない! –レビューワーはVMが無料で借りられます! As part of an ongoing effort to encourage patch review for the PostgreSQL project, we will be funding cloud servers for patch reviewers and testers who need them for CommitFests. That is, if you want to help with reviewing or testing a patch for a CommitFest, and don't have your own test server to use, the PostgreSQL project (via our funds at Software In the Public Interest) will pay for you to use a cloud server for the duration of your review/testing. So, if "I don't have anywhere to test it" was your excuse for not reviewing in the past, time to stop making excuses and start reviewing! Since these are cloud servers, they won't work well for performance testing. However, they will be excellent for testing replication. If you need one of these, please contact me to allocate a VM for you. 2013-07-13 Josh Berkus氏のメールより
  39. 39. 39 パッチレビュー(5) • レビューしたいけど環境がない! – VMでCentOS入れとけば十分です! • Windowsでのビルドはちょっと手間がかかるので 、Linux環境がお勧め – 一応マニュアルにやり方載ってます • 逆に言うと、Windows環境でもレビューすると喜 ばれるでしょう! – Macならいくつかツール入れれば簡単に用意で きます
  40. 40. 40 開発環境の用意(1) • 開発環境に必要なもの – OS • Unix、Linux、Mac OS Xなど –ツール • gccなどのCコンパイラ • bison/fex/perl • DocBook(ドキュメントコンパイル用) • git • お好みのエディタ(私はvim)
  41. 41. 41 開発環境の用意(2) • ソース持ってきましょう – gitで開発リポジトリをクローン • git://git.postgresql.org/git/postgresql.git • 全versionの変更履歴が手元に届きます • githubにもミラーがあります [tmp]$ time git clone git://git.postgresql.org/git/postgresql.git Cloning into 'postgresql'... remote: Counting objects: 478279, done. remote: Compressing objects: 100% (81023/81023), done. remote: Total 478279 (delta 400814), reused 472740 (delta 395295) Receiving objects: 100% (478279/478279), 137.90 MiB | 1.81 MiB/s, done. Resolving deltas: 100% (400814/400814), done. real 2m9.138s user 0m32.854s sys 0m6.458s 新宿のルノアールのau wifで計測 au LTEでは7分程度
  42. 42. 42 開発環境の用意(3) • パッチ当てる場合は、ブランチに注意 – 次バージョンはmasterブランチで開発 • 過去バージョンはREL9_3_STABLEなどのブランチ [postgresql(master)]$ git branch -r origin/HEAD -> origin/master origin/REL2_0B origin/REL6_4 origin/REL6_5_PATCHES origin/REL7_0_PATCHES origin/REL7_1_STABLE ... origin/REL8_3_STABLE origin/REL9_1_STABLE origin/REL9_2_STABLE origin/REL9_3_STABLE origin/Release_1_0_3 origin/WIN32_DEV origin/ecpg_big_bison origin/master [postgresql(master)]$
  43. 43. 43 開発環境の用意(4) • ソースコードの構成 [postgresql(master)]$ ls -F | cat COPYRIGHT 著作権表記 GNUmakefile.in Makefile生成元 Makefile Makefile README PostgreSQLの簡単な説明 README.git INSTALL等がない説明 aclocal.m4 autoconf用ファイル config/ autoconf用ファイル群 configure* configureスクリプト configure.in contrib/ contribモジュール doc/ ドキュメントのソース src/ プログラムソース
  44. 44. 44 開発環境の用意(5) • ソースコードの構成(src) [postgresql(master)]$ ls -F src/* | cat backend/ bin/ common/ include/ interfaces/ makefiles/ pl/ port/ template/ test/ timezone/ tools/ tutorial/ バックエンドサーバ OSコマンド(psqlやpg_dumpなど) フロントエンド/バックエンド共通 ヘッダファイル フロントエンドI/F(libpqやECPG) ビルド用ファイル 手続き言語(PL/pgSQLやPL/Perlなど) 環境依存コード 環境依存のビルド設定 リグレッションテスト タイムゾーンデータベース 開発用ツール群 SQLチュートリアル
  45. 45. 45 開発環境の用意(6) • ソースコードの構成(src/backendの一部) [postgresql(master)]$ ls -F src/backend/* | cat access/ bootstrap/ catalog/ commands/ executor/ optimizer/ parser/ postmaster/ replication/ rewrite/ storage/ tcop/ アクセスメソッド(インデックス) 起動・初期化 システムカタログ定義 SQLコマンド エグゼキュータ プランナ・オプティマイザ パーサ サーバプロセスのエントリポイント レプリケーション関連 リライタ バッファ・ストーレジ・ロック管理 リクエストディスパッチ(Trafc COP)
  46. 46. 46 開発環境の用意(7) • PostgreSQLの処理の流れ – クライアントがクエリ実行 – バックエンド(postgres)がメッセージを受け付ける – パーサがクエリ文字列を解析し構文木を生成 • 解析の過程でカタログを参照 – リライタが構文木を書き換え(ビュー展開など) – プランナ・オプティマイザが実行計画を生成 • 生成の過程で統計情報を参照 – エグゼキュータが実行計画に基づいて実行 • 共有バッファや抽象化されたストレージを利用 – 結果をクライアントに返却
  47. 47. 47 PostgreSQLのビルド • いつも通りの3ステップです – confgure、make、make install • ただし、レビュー・開発用には少し工夫を – --enable-cassert • Assert()マクロを有効化して、プログラムバグの検出を容易に(これ がないといきなりクラッシュしたり) – --enable-debug • コンパイラに-gオプション渡したり – --prefx=$HOME/pgsql-study • インストール先を分けたり – CFLAGS=-O0 • コンパイラの最適化を無効にして関数や変数を実体化
  48. 48. 48 ソース読んでみましょう(1) • とりあえず、もう一工夫 –タグファイルを作成してタグジャンプしましょ う• src/tools/make_ctags • src/tools/make_etags • さて、どこから読みましょう?
  49. 49. 49 ソース読んでみましょう(2) • まずはエグゼキュータやSQLコマンドあた りがお手頃 – SELECTってどう動くの? – VACUUMって結局何やってるの? – EXPLAINのJSONフォーマットってどう実現し ているの? • 慣れてきたら、普段気になっている部分を 見てみるのも
  50. 50. 50 動きを見てみましょう • gdbを使って処理を追ってみましょう – psqlで接続 – pg_backend_pid()でバックエンドプロセス特定 – gdbでアタッチ – 適当なところにブレークポイント設定 • exec_simple_query()→1クエリ実行の流れ • errfnish()→エラー発生箇所を特定 – psqlからクエリ実行(または適当なアクション) – gdbでブレークしたところからステップ実行
  51. 51. 51 改造してみましょう(1) • ソースコードは書き換え放題! – オープンソースですから。 – gitでブランチ切っておくと幸せになれます • いつでも戻せる、差分が分かる、Etc. – ソース書き換えたら、新しいバイナリに切り替え • ビルド、インストール、再起動が必要! • ビルドはsrc/backendで実行すればOK
  52. 52. 52 改造してみましょう(2) • デバッグ時のTips – elog()でのprintfデバッグ • プロトタイプ:elog(level, fmt, ...) • 例: int func(int param) { int foo; elog(WARNING, "%s() called with %d", __FUNCTION__, param); ... elog(WARNING, "foo = %d before xxx", foo); exec_xxx(...); elog(WARNING, "foo = %d after xxx", foo); ... }
  53. 53. 53 改造してみましょう(3) • デバッグ時のTips – NodeTag • NodeTagオブジェクト種別識別子 • 構造体の先頭にNodeTagを置き、その値でオブ ジェクト種別を識別 /* * The first field of a node of any type is guaranteed to be the NodeTag. * Hence the type of any node can be gotten by casting it to Node. Declaring * a variable to be of Node * (instead of void *) can also facilitate * debugging. */ typedef struct Node { NodeTag type; } Node;
  54. 54. 54 改造してみましょう(4) – NodeTag(続き) typedef struct JoinExpr { NodeTag type; JoinType jointype; /* type of join */ bool isNatural; /* Natural join? Will need to shape table */ Node *larg; /* left subtree */ Node *rarg; /* right subtree */ List *usingClause; /* USING clause, if any (list of String) */ Node *quals; /* qualifiers on join, if any */ Alias *alias; /* user-written alias clause, if any */ int rtindex; /* RT index assigned for join, or 0 */ } JoinExpr;
  55. 55. 55 提案してみましょう(1) • どんなネタで? – バグを修正(CF外で提案可能) • pgsql-bugsにもネタあり – 欲しい機能を実現 • pgsql-generalにもネタあり – 遅い部分を改善 • pgsql-performaneにもネタあり – TODOリストからピックアップ • http://wiki.postgresql.org/wiki/Todo – ドキュメント間違いを修正 • pgsql-doc
  56. 56. 56 提案してみましょう(2) • 提案のステップ – pgsql-hackersに外部仕様等を提案 – 意見がまとまってきたらPoCパッチを作成したり – コンセンサスが得られたらCommitFestに登録 – CommitFestが始まったら • 他者のパッチをレビュー • レビューコメントに対応 – Committed! • or Returned with Feedback→再挑戦…
  57. 57. 57 提案してみましょう(3) • 提案のポイント – 実装の前に設計 • いきなり実装せず、設計を議論(将来性・拡張性を重視) • 最初は難しいので、否定されてもくじけずにチャレンジを! – 意見がまとまってきたらPoCパッチ • 動きを見せると意外と意見が変わります • コーナーケースもきちんと見ましょう! – コーディングは周辺に合わせて! • 不用意に関係ない箇所を書き換えない! • バックパッチのし易さも重要な基準です – とにかく議論! • 「Low-context」の世界です
  58. 58. 58 開発関連の情報源 • Development Information(PostgreSQL wiki) – 開発者向け情報 – http://wiki.postgresql.org/wiki/Development_information • Developer FAQ – 開発のことを知りたい人はまずここを熟読すべし – http://wiki.postgresql.org/wiki/Developer_FAQ • hackers-jp – JPUG主催の開発者向け?日本語ML – http://ml.postgresql.jp/mailman/listinfo/hackers-jp
  59. 59. 59 PostgreSQLの情報源 • 日本PostgreSQLユーザ会 – 日本でのPostgreSQLの普及等 – 勉強会も年4回程度開催(Ustream中継あり) – http://www.postgresql.jp • Let's Postgres – 日本語情報のポータルサイト – http://lets.postgresql.jp • pgsql-jp – JPUG主催のユーザ向け日本語ML – http://ml.postgresql.jp/mailman/listinfo/pgsql-jp
  60. 60. 60 おわりに • ご清聴ありがとうございました。

×