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

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

5. © 2022 NTT DATA Corporation 5 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の信頼性が高くなくてはその価値が無いことを理解しています。十分テストして、安定したコードに対してバグを最小にしてからリリースするように努めてます。・バグレポートガイドライン https://www.postgresql.jp/document/current/html/bug-reporting.html 最大限の注意を払っても、全てのプラットフォーム、全ての環境でPostgreSQLの機能全てが正常に動くことは保証できません。

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

7. © 2022 NTT DATA Corporation 7 バグと見なされなかった例 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のまま

8. © 2022 NTT DATA Corporation 8 コミュニティの賛同でバグ扱いになることも 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; レプリケーションリカバリリカバリ処理が完全停止したように見えるほど、リカバリ性能が大幅に劣化することがあった

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

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

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

13. © 2022 NTT DATA Corporation 13 既知バグの確認例期待する挙動 =# 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は、現在のトランザクションをコミットして、そのトランザクションと同じ特性(トランザクション分離レベルなど)で次のトランザクションをすぐに開始するコマンド既知バグの例

14. © 2022 NTT DATA Corporation 14 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)以降で問題が再現するか確認し、再現しなければ既知バグと判断できる。

15. © 2022 NTT DATA Corporation 15 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

16. © 2022 NTT DATA Corporation 16 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)を指定できる

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

18. © 2022 NTT DATA Corporation 18 各情報源の対応付け 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 Author: Fujii Masao <fujii@postgresql.org> 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上の議論

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

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

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

23. © 2022 NTT DATA Corporation 23 バグ報告先バグ報告先説明 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はモデレータ付のため、メールの配送が遅延する可能性がある

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

26. © 2022 NTT DATA Corporation 26 バグ報告例その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

27. © 2022 NTT DATA Corporation 27 バグ報告例その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 問題の概要とバージョン情報問題の再現手順エラーメッセージとスタックトレース

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

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

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

33. © 2022 NTT DATA Corporation 33 デバッガによるバックエンドプロセスの処理実装の確認 ① 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

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

35. © 2022 NTT DATA Corporation 35 バグの原因となったコミットの特定以前は期待通りの挙動で、いつの間にか問題が発生するようになったバグについては、バグを混入させたコミットを特定することで、バグ解析や修正検討の役に立つ。例えば、以下では、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 Author: Fujii Masao <fujii@postgresql.org> Date: Tue Jul 12 11:53:29 2022 +0900 Fix assertion failure and segmentation fault in backup code. バグ解析 2 PostgreSQLをコンパイル、起動して、問題を再現させるSQLなどを実行

36. © 2022 NTT DATA Corporation 36 パッチを作成するブランチバグ修正パッチは、バグを確認したバージョンのブランチではなく、基本的に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

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

38. © 2022 NTT DATA Corporation 38 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 が動かなくなる。

39. © 2022 NTT DATA Corporation 39 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

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

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

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

Recommended

More Related Content

What's hot

What's hot(20)

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

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

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation(20)

Recently uploaded

Recently uploaded(14)