PostgreSQLのバグとの付き合い方～バグの調査からコミュニティへの報告、修正パッチ投稿まで～（Open Source Conference 2023 Online/Fall 発表資料）

© 2023 NTT DATA Group Corporation
© 2023 NTT DATA Group Corporation
オープンソースカンファレンス2023 Online/Fall
PostgreSQLのバグとの付き合い方
～バグの調査からコミュニティへの報告、修正パッチ投稿まで～
2023年9月29日
株式会社NTTデータグループ
藤井雅雄

© 2023 NTT DATA Group Corporation 2
自己紹介
藤井雅雄
Database Technical Lead @ NTTデータグループ
データベース研究開発
PostgreSQL 技術支援
PostgreSQLコミッタ
レプリケーション
WAL圧縮
バックアップ進捗確認
pg_bigm(全文検索モジュール) コミッタ
fujii_masao
MasaoFujii

本講演について
講演資料は、NTTデータのSlideShareアカウント上で公開予定です。
https://www.slideshare.net/nttdata-tech
本講演では、PostgreSQLドキュメントにあるバグレポートガイドラインに沿いつつ、
一部主観や実例を交えながら、PostgreSQLのバグとの使い方を説明します。
・バグだと思ったら・・・ PostgreSQLのバグの確認方法
・コミュニティに共有しよう・・・バグ報告のやり方
・修正パッチを書いてみよう・・・パッチ提供と議論
(*) バグレポートガイドライン
https://www.postgresql.jp/document/current/html/bug-reporting.html

PostgreSQLにおけるバグ

PostgreSQLはバグが少ないと言われることがあるが
2011 Coverity Scan Open Source Integrity Report
不具合密度(1000行あたりの不具合の数)が、
「Linux 2.6: 0.62」＞「OSS平均: 0.45」＞「PostgreSQL 9.1: 0.21」
https://codezine.jp/article/detail/6436
PostgreSQL開発コミュニティの信頼性に対する姿勢
・ PostgreSQLの信頼性に関するFAQ
https://wiki.postgresql.org/wiki/FAQ/ja#.E4.BF.A1.E9.A0.BC.E6.80.A7.28Reliability.29
我々は、DBMSの信頼性が高くなくてはその価値が無いことを理解しています。
十分テストして、安定したコードに対してバグを最小にしてからリリースするように努めてます。
・バグレポートガイドライン
最大限の注意を払っても、全てのプラットフォーム、全ての環境でPostgreSQLの機能全てが
正常に動くことは保証できません。

PostgreSQLにおけるバグとは
バグと見なされるのは、ドキュメントなどで謳っている仕様と実際の挙動が異なるケース
・各プログラムが、入力に対して間違った(仕様とは異なる)結果を返却する
・ PostgreSQL提供の各プログラムが、セグメンテーションフォルトなどで意図せずクラッシュする ...など
仕様として謳われていないことを問題報告してもバグとは見なされない
・仕様にない(まだサポートされていない)機能が利用できない
・各プログラムの実行性能が単に低い ...など
最終的には、バグと見なされるかどうかは、コミュニティ内の議論で決まる

バグと見なされなかった例
pg_stat_statements: rows not updated for CREATE TABLE AS SELECT statements
https://www.postgresql.org/message-id/flat/1584293755198-0.post%40n3.nabble.com
・ v13で、CREATE TABLE AS SELECTなどのユーティリティコマンドが取り扱った行数が、
pg_stat_statementsのrowsカラムにカウントされない
・ユーティリティコマンドによるrowsカラムのカウントについて、v13ではドキュメントにそのような仕様がなく、
バグではなく機能不足と見なされて、v13では改修されず、v14で新機能として取り込み
=# CREATE TABLE test AS SELECT * FROM pg_class;
SELECT 387
=# SELECT query, calls, rows FROM pg_stat_statements WHERE query LIKE 'CREATE TABLE test%';
-[ RECORD 1 ]--------------------------------------
query | CREATE TABLE test AS SELECT * FROM pg_class
calls | 1
rows | 0
v13以前では、CREATE TABLE AS SELECTで
387行を取り扱ったのに、rowsカラムは0のまま

コミュニティの賛同でバグ扱いになることも
Speedup of relation deletes during recovery
https://www.postgresql.org/message-
id/flat/CAHGQGwHVQkdfDqtvGVkty%2B19cQakAydXn1etGND3X0PHbZ3%2B6w%40mail.gmail.com
・ v11において、同一トランザクション内で複数のリレーションを削除すると、そのリカバリ性能が大幅に劣化
・この問題は仕様に反しているわけではないが、既存ユーザへの問題の影響などから、
コミュニティ内の複数の開発者がバグ扱いとすることに賛同して、v11にも問題の改修を取り込み
プライマリスタンバイ
BEGIN;
DROP TABLE tbl01;
DROP TABLE tbl02;
...
COMMIT;
レプリケーション
リカバリ
リカバリ処理が完全停止したように見えるほど、
リカバリ性能が大幅に劣化することがあった

バグ修正の取り込み
バグ修正は、サポート対象のバージョン(v11～v16)と現在開発中のバージョン(v17dev)に取り込み
※()内は2023年9月29日時点のバージョン
PostgreSQL開発コミュニティは、メジャーバージョンについて初回リリースから約5年間をサポート
https://www.postgresql.org/support/versioning/
サポート終了した古いバージョン
についてはバグ修正されない！

バグだと思ったら・・・
PostgreSQLのバグの確認方法

問題解決の流れ
問題の検知
問題やトラブル、期待通りでない挙動を検知する。
問題の分析や解決に必要な情報を収集する。
問題の切り分け
問題の原因となる誤り・ミス(操作誤り、設定誤り、ドキュメントの読
み違いなど)がないか確認する。
誤り・ミスの確認
問題の原因となる既知バグがないか確認する。
コミュニティへの問題報告などにより未知バグを確認する。
バグの確認
原因に応じた対策を実施して、問題を解決する。
1
2
3
4
問題の解決
5
問題の発生個所を特定する。
PostgreSQL、エクステンション、アプリケーション、OSなど
繰
り
返
し

既知バグの確認
PostgreSQL開発コミュニティにはバグ管理システムがない
バグ管理システムから、バグの報告内容や関連する議論、バグの対応ステータス(非バグ、未修正、修正対応中、
修正済など)などを確認できない。
PostgreSQLコミュニティの複数の情報源から既知バグかどうか確認する必要がある
1. 各マイナーバージョンのリリースノート
2. ソースレポジトリのコミットログ
3. PostgreSQL開発コミュニティのML
4. 日本PostgreSQLユーザ会のMLやSlackチャンネル
5. PostgreSQL関連ブログ記事など一般サイト
など

既知バグの確認例
期待する挙動
=# BEGIN;
=*# SAVEPOINT s1;
=*# CREATE TABLE test (i int);
=*# COMMIT AND CHAIN;
=*# INSERT INTO test VALUES (1);
=*# ROLLBACK;
=# SELECT count(*) FROM test;
count
-------
0
(1 row)
v13.1での挙動
=# BEGIN;
=*# SAVEPOINT s1;
=*# CREATE TABLE test (i int);
=*# COMMIT AND CHAIN;
=# INSERT INTO test VALUES (1);
=# ROLLBACK;
WARNING: there is no transaction in progress
=# SELECT count(*) FROM test;
count
-------
1
(1 row)
・ v13.1において、SAVEPOINTがあるトランザクションでCOMMIT AND CHAINを
実行したとき、次のトランザクションが開始されない
・ COMMIT AND CHAINは、現在のトランザクションをコミットして、そのトランザクションと
同じ特性(トランザクション分離レベルなど)で次のトランザクションをすぐに開始するコマンド
既知バグ
の例

1. リリースノートからの既知バグの確認例
問題が発生したマイナーバージョンの次のバージョンから、最新のマイナーバージョンまで、リリースノートを見て、
問題の修正が含まれていないか確認する。
各マイナーバージョンのリリースノートは、そのメジャーバージョンのドキュメントに含まれる。
例えば、v13.xのリリースノートは、v13のドキュメントから確認できる。
https://www.postgresql.org/docs/13/release.html
今回の例ではv13.1で問題が発生したため、v13.2以降のリリースノートを確認していく。
v13.3のリリースノートに今回の問題のバグ修正を確認できる。
Fix COMMIT AND CHAIN to work correctly when the current transaction has
live savepoints (Fujii Masao)
https://www.postgresql.org/docs/13/release-13-3.html
バグ修正を確認できたマイナーバージョン(今回はv13.3)以降で問題が再現するか確認し、再現しなければ
既知バグと判断できる。

2. コミットログからの既知バグの確認例
バグ修正のコミットを特定するための検索キーワードを決めて、①～④の方法で確認する。
今回の例では、「commit and chain」や「savepoints」を検索キーワードにする。
① 手元環境にcloneしたgitソースレポジトリからgitコマンドで確認
$ git clone -b REL_13_STABLE git://git.postgresql.org/git/postgresql.git
$ git log --grep="commit and chain" --grep="savepoints" -i --all-match
② PostgreSQLの公式gitソースレポジトリで検索
https://git.postgresql.org/gitweb/?p=postgresql.git;a=shortlog;h=refs/heads/REL_13_STABLE
③ GitHubにミラーされているPostgreSQLの
gitソースレポジトリで検索
https://github.com/postgres/postgres
④ pgsql-committersのMLで検索
https://www.postgresql.org/search/?m=1

ML 説明
pgsql-hackers 新機能の提案やバグ修正、開発課題などについて議論する
pgsql-bugs ユーザからのバグ報告先。報告されたバグやその修正などについて議論する
pgsql-docs ドキュメントやその問題、改修などについて議論する
pgsql-committers コミットされた内容が通知される
3. PostgreSQL開発コミュニティのMLからの既知バグの確認例
PostgreSQL開発コミュニティでのコミュニケーションはMLが基本
・ PostgreSQL公式サイトでコミュニティアカウントを作成することでMLを購読できる。
・バグ修正について議論されやすいMLは以下。
バグ修正の議論を特定するための検索キーワードを決めて、
MLの過去議論検索ページから確認する。
・今回の例では、「commit and chain」と「savepoints」を
検索キーワードにする。
https://www.postgresql.org/search/?m=1
検索ページでは、検索キーワード(Search term)、
検索対象のML(List)、検索対象の期間(Date)、
検索結果の表示順(Sort By)を指定できる

既知バグを確認する各情報源の特徴
項
番
情報源
修正済かつ
リリース済
修正済かつ
未リリース
未修正
(未リリース)
1
各マイナーバージョンの
リリースノート ○
2
ソースレポジトリの
コミットログ ○ ○
3
PostgreSQL
開発コミュニティのML ○ ○ ○
各情報源から確認できるバグの種類
開発者含む専門的なやりとり
具体的な情報
長大な議論
ユーザ向けの記述
概要レベルの情報
簡潔な説明

各情報源の対応付け
1. リリースノートのソース
https://github.com/postgres/postgres/blob/REL_13_STABLE/doc/src/sgml/release-13.sgml

<para>
Fix <command>COMMIT AND CHAIN</command> to work correctly when the
current transaction has live savepoints (Fujii Masao)
</para>
2. コミットログ
$ git show 422012c98
commit 422012c98f8d929f9aa2b2e706b29512f61544e1
Date: Fri Feb 19 21:57:52 2021 +0900
Fix bug in COMMIT AND CHAIN command.
(略)
Reported-by: Arthur Nascimento
Author: Fujii Masao
Reviewed-by: Arthur Nascimento, Vik Fearing
Discussion: https://postgr.es/m/16867-3475744069228158@postgresql.org
リリースノートのソースに記載されている、各改修項目
のコミットIDから、対応するコミットログを特定
コミットログに記載されているURLから、
対応するML上の議論を特定
3. ML上の議論

既知バグの修正の取り込み
バグが修正されたマイナーバージョン(まだ未リリースであればリリースを待ってから)に
アップデートすることで、バグ修正を取り込み
• 既知バグの修正をすべて取り込めるように最新マイナーバージョンへのアップデートも検討する
• ただし、取り込みたいバグ修正以外にも複数の改修項目がマイナーバージョンに含まれるため、必要に
応じてそれらがシステムやアプリケーションに影響しないか確認する必要がある
• PostgreSQL開発コミュニティは、特定のバグ修正を個別パッチとして取り込む方法を提供しない

コミュニティに共有しよう・・・
バグ報告のやり方

問題解決の流れ
問題の検知
問題やトラブル、期待通りでない挙動を検知する。
問題の分析や解決に必要な情報を収集する。
問題の切り分け
問題の原因となる誤り・ミス(操作誤り、設定誤り、ドキュメントの読
み違いなど)がないか確認する。
誤り・ミスの確認
問題の原因となる既知バグがないか確認する。
コミュニティへの問題報告などにより未知バグを確認す
る。
バグの確認
原因に応じた対策を実施して、問題を解決する。
1
2
3
4
問題の解決
5
問題の発生個所を特定する。
PostgreSQL、エクステンション、アプリケーション、OSなど
繰
り
返
し

バグ報告にあたり
バグレポートガイドライン
PostgreSQLに関してバグを発見した場合、ぜひ我々に連絡してください。
バグレポートはPostgreSQLをより信頼性の高いものにするために、大変重要になります。
・・・
私たちは、すべてのバグを直ちに修正することを約束することはできません。
そのバグが明確で、重大で、あるいは他の多くのユーザにも影響を与えるものであれば、
誰かがすぐに調査する可能性が高くなるでしょう。
・・・
現在計画中の大きな変更が終了するまで、バグを修正できないと判断する場合もあります。
また、単に修正が非常に困難であり、より重要な他の事項があることもあります。
早急に処置が必要な場合は、商用サポートの購入を検討してください。

バグ報告先
バグ報告先説明
pgsql-bugs@lists.postgresql.org バグ報告先のML。報告されたバグやその修正などについて議論される
https://www.postgresql.org/acc
ount/submitbug/
バグ報告用Webフォーム。利用にはPostgreSQLコミュニティサイトへのサ
インインが必要。報告内容はpgsql-bugsのMLに送信される
pgsql-docs@lists.postgresql.org ドキュメントのバグ報告先のML。報告されたバグやその修正などについて議
論される
security@postgresql.org セキュリティ問題のバグ報告先の非公開ML。MLには限られたメンバのみ参
加し、バグやその修正などについて非公開で議論される
報告するバグごとに適切な報告先を選ぶ
注意事項
• セキュリティ問題のバグなど公開が望ましくない報告は、pgsql-bugsやpgsql-docsの公開MLにしないこと
• ユーザ向けML(pgsql-generalなど)や開発者向けML(pgsql-hackers)には、基本的にバグ報告しないこと
• MLはモデレータ付のため、メールの配送が遅延する可能性がある

バグ報告用Webフォーム
https://www.postgresql.org/
https://www.postgresql.org/account/submitbug/

報告すべきこと
問題やバグについて、事実のみをありのままに報告すること
① 問題を再現できる明確で具体的な手順
② 問題発生時の出力結果そのもの
SQL実行結果、エラーメッセージ、スタックトレースなど
③ どのような挙動や実行結果を期待していたか
④ プログラムに指定したオプションやデフォルトから変更した設定パラメータ値
⑤ PostgreSQLのバージョン
可能であれば最新マイナーバージョンや最新メジャーバージョンで問題が再現するかの情報
⑥ プラットフォーム情報
OSの種類やバージョンなど
PostgreSQL開発者自身が問題を再現できることが、
バグ修正のための最大の一歩！！

バグ報告例その1
Fix error message for MERGE foreign tables
https://www.postgresql.org/message-id/flat/af88be42757c90e163fc4e27a2e29e0e%40oss.nttdata.com
外部テーブルへの
直のMERGE実行では
期待通りのエラーメッセージ
パーティションテーブル経由の
外部テーブルへの
MERGE実行では
想定外のエラーメッセージ
パーティションテーブルA
ﾃｰﾌﾞﾙ
A2
外部
ﾃｰﾌﾞﾙ
A1
ﾃｰﾌﾞﾙ
A3
MERGE

バグ報告例その2
Backup command and functions can cause assertion failure and segmentation fault
https://www.postgresql.org/message-id/flat/3374718f-9fbf-a950-6d66-d973e027f44c%40oss.nttdata.com
問題の概要と
バージョン情報
問題の
再現手順
エラーメッセージと
スタックトレース

バグ報告へのよくある反応と必要な対応
報告の問題をバグとして取り扱うべき根拠などを見直し、改めて説明する。
これは期待通りの挙動で、
バグではありません！
再現手順やその前提となる条件・設定などに漏れ・誤りがないか見直し、
再現手順を改めて提供する。
私の環境では問題を
再現できませんでした。
可能であれば、最新のマイナーバージョンやメジャーバージョンで問題が
再現するか確認した結果を報告する。
最新バージョンでも
問題は再現しますか？
コミュニティWikiに記載の方法で、
問題発生時のスタックトレースを取得して報告する。
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
問題発生時のスタックトレース
を提供してください。
必要な対応
よくある反応
可能であれば、手元にPostgreSQLの開発環境を用意して、
パッチを適用した版で問題が解消するか確認した結果を報告する。
バグ修正パッチを作成しました。
このパッチで問題が解消します
か？

報告したバグの修正がコミットされると
バグの報告者として名前が
コミットログに掲載される！
以降、バグ修正されたマイナーバージョンがリリースされたら、アップデートすることでバグ修正を取り込み

修正パッチを書いてみよう・・・
パッチ提供と議論

バグ修正パッチを本当に自分が書くべきか？
基本的に、バグ修正パッチの作成はコミュニティの開発者に任せた方が、バグをいち早く確実に解消できる。
バグ修正に関与したい場合も、ML上での技術的な議論への参加やパッチレビューから始めるのがよい。
参考: 「PostgreSQL開発コミュニティに参加しよう！（PostgreSQL Conference Japan 2021 発表資料）」
https://www.slideshare.net/nttdata-tech/postgresql-global-development-group-postgresql-conference-japan-2021-nttdata
もし書くとしたら
• バグ報告したが、誰も修正パッチを作成してくれないため
• パッチ作成を通じて、PostgreSQLの実装を学びたいため
• バグ修正者としてリリースノートに自分の名前を載せたい
などあるが・・・

バグ修正パッチの開発の流れ
開発環境準備
バグ解析
パッチ作成
パッチ投稿
1
2
3
4
レビュー対応
5
繰
り
返
し
コミット
6
パッチを作成、適用、コンパイル、テストできる開発環境を準備する
バグ関連のソースを読み、デバッガで動きを追い、バグやその原因を
実装レベルで解析する
バグを修正するパッチを作成して、パッチにより問題が解消すること
を確認する
コミュニティでパッチをレビューして、パッチの不備を改修する
コミッタがバグ修正パッチをPostgreSQLに取り込む
バグの報告とともに修正パッチをコミュニティに投稿する

デバッガによるバックエンドプロセスの処理実装の確認
① PostgreSQLをデバッガで追いやすいように、--enable-debugとCFLAGS=-O0を指定してコンパイルする。
$ ./configure --prefix=/opt/pgsql --enable-debug --enable-cassert --enable-tap-tests CFLAGS=-O0
$ make -j 4 install
② PostgreSQLを起動して、psqlからPostgreSQLに接続し、バックエンドプロセスのpidを取得する。
$ initdb -D data --no-locale --encoding=UTF8
$ pg_ctl -D data start
$ psql
=# SELECT pg_backend_pid();
③ gdbを起動して、②で取得したpidを指定してバックエンドプロセスにアタッチする。以下ではEmacs経由でgdb実行。
$ emacs &
Emacs内で M-x gdb コマンドでgdbを起動
(gdb) attach <②で取得のpid>
バグ解析
2
VSCodeでデバッグしたい場合は、
発表資料「VSCodeで作るPostgreSQL開発環境」を参考に。
https://www.slideshare.net/nttdata-tech/postgresql-vscode-
development-environment-pgunconf25-nttdata

デバッガによるバックエンドプロセスの処理実装の確認
④ PostgreSQL内の関数をブレークポイントに設定する。
例えば、SQL実行の起点となるexec_simple_query関数を設定する。
(gdb) b exec_simple_query
⑤ ②で起動のpsqlから、デバッガで処理を追いたいSQLを実行する。
以下ではCOMMIT AND CHAINの処理実装を確認。
=# COMMIT AND CHAIN;
⑥ デバッガをブレークポイントまで進めて、
以降は、gdbのコマンドを使って、処理を1ステップずつ進めたり、変数の内容を調査するなどして処理実装を追っていく。
(gdb) c
(gdb) ...
バグ解析
2

バグの原因となったコミットの特定
以前は期待通りの挙動で、いつの間にか問題が発生するようになったバグについては、バグを混入させたコミットを特定す
ることで、バグ解析や修正検討の役に立つ。
例えば、以下では、v13.4以降でバグを混入させたコミットをgit bisectで特定する。
① v13のブランチで、git bisectの探索範囲としてv13.4(REL_13_4)から最新(HEAD)までを指定する。
$ git checkout REL_13_STABLE
$ git bisect start HEAD REL_13_4
② バグを試験するスクリプトを用意して、git bisectでバグを混入させたコミットを探索する。
$ git bisect run /PATH_TO/test_script.sh
...
162ade612f1543389bd105fba82ea7e60c5b82c9 is the first bad commit
commit 162ade612f1543389bd105fba82ea7e60c5b82c9
Date: Tue Jul 12 11:53:29 2022 +0900
Fix assertion failure and segmentation fault in backup code.
バグ解析
2
PostgreSQLをコンパイル、起動して、
問題を再現させるSQLなどを実行

パッチを作成するブランチ
バグ修正パッチは、バグを確認したバージョンのブランチではなく、基本的にmasterブランチに対して作成する。
masterブランチへのパッチのコミット時に、コミッタが、バグが存在する他のバージョンへのバックポートを行う。
① masterブランチでソースを最新化して、バグ修正用のブランチを作成する。
$ git checkout master
$ git pull
$ git checkout -b bugfix
② バグを修正して、その修正内容をコミットする。
$ emacs ...
$ git commit -a -m "Fix bug ..."
③ masterブランチからバグ修正用ブランチへのソース差分をパッチとして作成する。
$ git format-patch master
$ ls *.patch
0001-Fix-bug.patch
パッチ作成
3

互換性の保証
マイナーバージョン間の互換性を保証するため、基本的に、バグ修正パッチは以下を変更してはならない。
• ユーザインタフェース
例えば、コマンドやオプション、設定パラメータなどの名前を変更すること
• システムカタログ
例えば、システム関数を追加・削除するなどしてpg_procなどのシステムカタログを変更すること
• データレイアウト
例えば、ストレージ上のDBデータやWALの物理レイアウトを変更すること
• 通信プロトコル
例えば、ストリーミングレプリケーションのプライマリからスタンバイへのWAL転送プロトコルを変更すること
• ABI (Application Binary Interface)
例えば、エクステンションなどから参照される可能性があるPostgreSQL内部の関数や構造体、変数などについて
名前や構造を変更すること
パッチ作成
3

ABIの互換性が保証されないとパッチ作成
3
エクステンション pg_exclusive_backup のソース
https://github.com/MasaoFujii/pg_exclusive_backup/blob/main/pg_exclusive_backup.c
PostgreSQL15のソース
https://github.com/postgres/postgres/blob/REL_15_STABLE/src/include/access/xlog.h
https://github.com/postgres/postgres/blob/REL_15_STABLE/src/backend/access/transam/xlog.c
例えば、PostgreSQLの内部関数 do_pg_backup_start() の名前や引数などが変更
されると、その関数を呼んでいるエクステンション pg_exclusive_backup が動かなくなる。

COMMIT AND CHAINや
SAVEPOINTを含む
テストしたいSQLを登録
テストするSQLの
あるべき実行結果を登録
テストの追加
将来的に同じバグが再度混入しないように、リグレッションテストにバグのテストを追加する。
https://www.postgresql.jp/document/current/html/regress.html
• テストを追加するには、テストしたいSQLとそのあるべき実行結果を登録する。
• リグレッションテストの実行では、登録されているSQLを実行して、その実行結果が登録されているあるべき実行結果と一致
するか確認する。
以下は、COMMIT AND CHAINとSAVEPOINTのバグ修正で追加されたテスト(の一部)
src/test/regress/sql/transactions.sql
+START TRANSACTION ISOLATION LEVEL REPEATABLE READ, READ WRITE, DEFERRABLE;
+SHOW transaction_isolation;
+SHOW transaction_read_only;
+SHOW transaction_deferrable;
+SAVEPOINT x;
+COMMIT AND CHAIN; -- TBLOCK_SUBCOMMIT
・・・
src/test/regress/expected/transactions.out
+START TRANSACTION ISOLATION LEVEL REPEATABLE READ, READ WRITE, DEFERRABLE;
+SHOW transaction_isolation;
+ transaction_isolation
+-----------------------
+ repeatable read
+(1 row)
・・・
パッチ作成
3

バグ修正パッチの投稿はいつでも
2022年度 2023年度
6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11
CF CF CF CF CF
v16開発
v15開発
v17開発
CF CF
Beta / RC
Beta / RC
Feature
Freeze リリース
リリース
コミュニティサポート
CF
CommitFest
パッチレビューに
集中する期間
パッチ投稿
4

バグ修正パッチのCommitFestへの登録
コミットまで時間がかかりそうな場合は、バグ修正パッチについてコミュニティが忘れてしまわないように、
直近のCommitFestに登録しておく。
https://commitfest.postgresql.org/
パッチ投稿
4

おわりに

困ったときは日本のコミュニティで相談も
例えば、ほぼ月1ペースで開催のアンカンファレンスでバグのLTをするなど

その他、記載されている会社名、商品名、又はサービス名は、
各社の登録商標又は商標です。

PostgreSQLのバグとの付き合い方～バグの調査からコミュニティへの報告、修正パッチ投稿まで～（Open Source Conference 2023 Online/Fall 発表資料）

PostgreSQLのバグとの付き合い方～バグの調査からコミュニティへの報告、修正パッチ投稿まで～（Open Source Conference 2023 Online/Fall 発表資料）

Recommended

More Related Content

Similar to PostgreSQLのバグとの付き合い方～バグの調査からコミュニティへの報告、修正パッチ投稿まで～（Open Source Conference 2023 Online/Fall 発表資料）

Similar to PostgreSQLのバグとの付き合い方～バグの調査からコミュニティへの報告、修正パッチ投稿まで～（Open Source Conference 2023 Online/Fall 発表資料）(20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation(20)

Recently uploaded

Recently uploaded(9)