PostgreSQLコミュニティをナビゲートするためのヒントとコツ

このブログは、PostgreSQLコミュニティ、それがどのように機能するか、そしてそれをナビゲートするための最良の方法についてです。これは単なる概要であることに注意してください...既存のドキュメントがたくさんあります。

コミュニティの概要、開発の仕組み

PostgreSQLは、PostgreSQLグローバル開発グループと呼ばれるリレーショナルデータベースコンピューティングに情熱を注ぐ高度なスキルを持つボランティアのグローバルに分散したネットワークによって開発および保守されています。少数のコアチームメンバーが一緒になって、リリースアクティビティの調整、特別な内部コミュニケーション、ポリシーの発表、コミット特権とホスティングインフラストラクチャの監視、懲戒およびその他のリーダーシップの問題、および特殊なコーディング、開発、保守の貢献領域に対する個々の責任などの特別な責任を処理します。 。その名前が示すように、重要なコードベース機能または密接に関連するプロジェクトの包括的な開発または保守活動を行った、約40人の追加の個人が主要な貢献者と見なされます。そして、さらに数十人の個人が積極的に他のさまざまな貢献をしています。アクティブな貢献者を除いて、過去の貢献者の長いリストがプロジェクトでの作業のために認められています。 PostgreSQLの豊富で堅牢な機能セットを生み出したのは、このチームのスキルと高い基準です。

貢献者の多くは、PostgreSQLまたは他のオープンソースソフトウェアに直接関連するフルタイムの仕事をしており、雇用主の熱心なサポートにより、PostgreSQLコミュニティとの永続的な関与が実現可能になっています。

貢献する個人は、インターネットリレーチャット（irc：//irc.freenode.net/PostgreSQL）やPostgreSQLコミュニティメーリングリスト（https://www.PostgreSQL.org/community/lists）などのコラボレーションツールを使用して調整します。 IRCまたはメーリングリストを初めて使用する場合は、エチケットとプロトコルを具体的に読んでください（https://fedoramagazine.org/beginners-guide-irc/に1つの優れた記事が表示されます）。参加した後は、自分の問題に飛び込む前に、進行中の会話を聞いてアーカイブを検索し、以前の同様の質問を探すこともあります。

チームは静的ではないことに注意してください。誰でも貢献することで貢献者になることができます…しかし、あなたの貢献は同じ高い基準を満たすことが期待されます！

チームはWikiページ（https://wiki.postgresql.org/）を管理しており、記事、チュートリアル、コードスニペットなどの非常に詳細で役立つ情報の中で、PostgreSQLのバグと機能リクエストのTODOリストを示しています。努力が必要となる可能性のある他の領域。チームの一員になりたい場合は、ここを閲覧するのに適しています。アイテムは、開発者のメーリングリストで十分に話し合った後にのみ追加されます。

コミュニティは、図1のステップとして視覚化されたプロセスに従います。

つまり、重要な新しいコード実装の価値は、最初に議論され、（コンセンサスによって）望ましいと見なされることが期待されます。次に、設計に投資します。インターフェースの設計、構文、セマンティクス、動作、および下位互換性の問題の考慮です。解決すべき問題と、この実装で何が達成されるかについて、開発者コミュニティから賛同を得たいと考えています。あなたは間違いなく自分で立ち去って何かを開発したくありません。チームには文字通り何十年にもわたる非常に質の高い集合的な経験があり、あなたはアイデアを早期に精査することを望んでおり、彼らはそれを期待しています。

PostgreSQLのソースコードはGitバージョン管理システムを使用して保存および管理されるため、https：//git.postgresql.org/からローカルコピーをチェックアウトして実装を開始できます。耐久性のある保守性のために、パッチは周囲のコードと融合し、確立されたコーディング規則（http://developer.postgresql.org/pgdocs/postgres/source.html）に従う必要があるため、同様のコードを検討することをお勧めします。規約を学び、エミュレートするセクション。通常、標準フォーマットのBSDスタイルが使用されます。また、必要に応じてドキュメントを更新してください。

テストでは、最初に既存の回帰テストが成功し、コンパイラの警告がないことを確認しますが、対応する新しいテストを追加して、新しく実装された機能を実行します。

ローカルリポジトリでの新しい機能の実装が完了したら、Gitdiff機能を使用してパッチを作成します。パッチは、レビューとコメントのためにpgsql-hackersメーリングリストに電子メールで送信されますが、作業が完了するまで待つ必要はありません…賢明な方法は、フィードバックを段階的に求めることです。 Wikiページには、フォーマットと役立つ説明コンテキストに関する期待と、コードレビューアの時間を尊重する方法が記載されています。

コア開発者は定期的にコミットフェストをスケジュールします。その間、蓄積されたすべての適用されていないパッチは、許可されたコミッターによってソースコードリポジトリに追加されます。寄稿者として、あなたのコードは厳密なレビューを受けており、おそらくあなた自身の開発者のスキルがそれにとってより良いでしょう。恩返しをするために、他の人からのパッチのレビューに時間を割くことが期待されています。

情報を入手したりPostgreSQLを学習したりするためのトップWebサイト

これなしでは生きていけないツール

PostgreSQLデータベースを操作するための基本的なコマンドラインツールは、正規分布の一部です。主力製品はpsqlコマンドラインユーティリティであり、データベースメタデータのクエリ、表示、変更、およびデータ定義（DDL）とデータ操作（DML）ステートメントの実行のための多くの機能を備えたインタラクティブなインターフェイスを提供します。

その他の注目すべきユーティリティには、レプリケーションベースのバックアップのベースラインを確立するためのpg_basebackup、データベースをスクリプトファイルまたは他のアーカイブファイルに抽出するためのpg_dump、pg_dumpアーカイブからを復元するためのpg_restoreなどがあります。これらのツールはすべて、優れたマニュアルページを備えているだけでなく、標準のドキュメントや多数のオンラインチュートリアルで詳しく説明されています。

pgAdminは、非常に人気のあるグラフィカルユーザーインターフェイスツールであり、psqlコマンドラインユーティリティと同様の機能を提供しますが、ポイントアンドクリックで便利です。図2は、pgAdminIIIのスクリーンショットを示しています。左側は、接続先のホストサーバー上のクラスター内のすべてのデータベースオブジェクトを示すパネルです。構造にドリルダウンして、すべてのデータベース、スキーマ、テーブル、ビュー、関数などを一覧表示したり、テーブルとビューを開いて含まれているデータを調べたりすることもできます。右下のパネルに示すように、ツールはオブジェクトごとに、オブジェクトをドロップして再作成するためのSQLDMLも作成します。これは、データベース開発中に変更を加えるための便利な方法です。

アプリケーション開発者チームのための私のお気に入りのツールのいくつかは、データベース変更管理用のSqitch（http://sqitch.org/）とpgTAP（http://pgtap.org/）です。 Sqitchは、PostgreSQLだけでなく、実装にネイティブなSQLダイアレクトで記述されたスクリプトを使用して、スタンドアロンの変更管理と反復型開発を可能にします。データベース設計の変更ごとに、3つのスクリプトを記述します。1つは変更を展開するため、1つは以前のバージョンに戻す必要がある場合に変更を元に戻すため、もう1つは変更を検証またはテストするためです。スクリプトと関連ファイルは、アプリケーションコードと一緒にリビジョン管理システムで管理できます。 PgTAPは、データベースの整合性を検証するための一連の機能を含むテストフレームワークです。すべてのpgTAPスクリプトは、同様に、通常のリビジョン管理および変更管理プロセスに準拠したプレーンテキストファイルです。これらの2つのツールを使い始めたら、データベースの作業をこれなしで行うことは想像もできませんでした。

ヒントとコツ

PostgreSQLの一般的なメーリングリストは、さまざまなコミュニティリストの中で最もアクティブであり、ユーザーを無料でサポートするための主要なコミュニティインターフェイスです。かなり幅広い質問がこのリストに表示され、時には長い往復が発生しますが、ほとんどの場合、迅速で有益な、的確な回答が得られます。

PostgreSQLの使用に関連する質問を投稿するときは、通常、使用しているPostgreSQLのバージョン（「psql--version」を使用してpsqlコマンドラインツールで一覧表示）、サーバーがインストールされているオペレーティングシステムなどの背景情報を常に含める必要があります。実行してから、オペレーティング環境の説明（主に読み取りが多いか書き込みが多いかなど）、一般的なユーザー数と同時実行性の懸念、デフォルトのサーバー構成（pg_hba.confなど）から行った変更postgresql.confファイル）など。多くの場合、自分で考えもしなかった改善の提案が得られる可能性があるため、達成しようとしていることの説明は、鈍い類推ではなく、価値があります。また、問題を説明し、他の人があなたが見ているものを再現するのを容易にする実際のDDL、DML、およびサンプルデータを含めると、最良の応答が得られます-はい、人々は実際にあなたのサンプルコードを実行し、あなたと協力します。

さらに、クエリパフォーマンスの向上について質問している場合は、クエリプラン、つまりEXPLAIN出力を提供する必要があります。これは、pgAdminツールまたはpsqlコマンドラインユーティリティの図3に示すように、文字通り「EXPLAIN」という単語を前に付けることを除いて、クエリを変更せずに実行することによって生成されます。

EXPLAINでは、サーバーは実際にクエリを実行する代わりに、クエリプランを返します。このプランには、データアクセスを最適化するために使用されるインデックス、テーブルスキャンが発生する可能性のある場所、推定値など、クエリの実行方法の詳細な出力が一覧表示されます。各ステップに関連するデータのコストと量。メーリングリストを監視している経験豊富な実務家から得られる種類のヘルプは、問題を特定し、フィルタリングまたは参加基準の新しいインデックスまたは変更の可能性を提案するのに役立つ場合があります。

最後に、メーリングリストのディスカッションに参加するときは、覚えておくべき2つの重要なことがあります。

まず、メールリストサーバーは、返信時にデフォルトでメールソフトウェアが元のメッセージ作成者にのみ返信するように構成されたメッセージを送信するように設定されています。メッセージが確実にリストに送信されるようにするには、メールソフトウェアの「全員に返信」機能を使用する必要があります。この機能には、メッセージの作成者とリストのアドレスの両方が含まれます。

第二に、PostgreSQLメーリングリストの慣例は、インラインで返信し、TOPPOSTではないことです。この最後の点は、このコミュニティでの長年の慣習であり、多くの新規参入者にとっては、穏やかな警告が非常に一般的であるほど珍しいようです。意見は、返信のコンテキストのために元のメッセージをどれだけ保持するかによって異なります。一部の人々は、元のメッセージ全体が何度も何度も議論されているときに、メッセージのサイズが扱いにくいほど大きくなることに悩まされます。私個人的には、メッセージを簡潔かつ集中的に保つために、具体的に返信している内容に関係のないものはすべて削除するのが好きです。歴史的文書や将来の調査のためにオンラインで保持されるメーリングリストの履歴は数十年あることを覚えておいてください。したがって、コンテキストとフローを保持することは非常に重要であると考えられています。

この記事では、始めて、次に進んで、飛び込んでください！