PostgreSQLへの貢献:実際のパッチの例、Nのパート1





記事「 PostgreSQLの貢献者になる」で、PostgreSQL開発プロセスとこの記事で使用したツールについて詳しく説明し、最初のパッチのいくつかのアイデアを提案し、これらのパッチをどこにどのように送信するかを伝えました。 RDBMSの内部構造に関する追加情報ソースへのリンクも提供されました。



ここで、最近PostgreSQLで採用された実際のパッチの例を見てみましょう。 これらのパッチのいくつかは私が直接作成したものであり、他のパッチを開発している間、私はレビューアとして積極的に参加しました。 これらは比較的小さなパッチです。 この記事の執筆時点では、PostgreSQLの開発は1年足らずで、これまでDBMS開発は行っていません(お金のためのC言語開発のように)。 したがって、これらのパッチは、オープンソースプロジェクトの開発に参加したい初心者にとって興味深いものになると信じる理由があります。さらに、必ずしもPostgreSQLであるとは限りません。 長文を書かないために、記事はいくつかの部分に分かれています。



興味のある方は猫に進んでください。



1. ReorderBufferCleanupTXN()の重複コードを削除する



私は、 さまざまな静的アナライザー 、特にClang Static Analyzerを使用して、PostgreSQLコードを随時調べていきます。 多くの場合、これらのアナライザーは疑わしいナンセンスを誓いますが、このナンセンスの中に非常に疑わしいコードが見つかる場合があります。 これらのピースの1つは次のようになりました。



/* delete from list of known subxacts */ if (txn->is_known_as_subxact) { /* NB: nsubxacts count of parent will be too high now */ dlist_delete(&txn->node); } /* delete from LSN ordered list of toplevel TXNs */ else { dlist_delete(&txn->node); }
      
      





同意して、ifブロックとelseブロックで同じことをするのはかなり奇妙です。 メーリングリストでこの問題を簡単に説明し、パッチを1回書き換えただけで、コードは次のようになりました。



 /* * Remove TXN from its containing list. * * Note: if txn->is_known_as_subxact, we are deleting the TXN from its * parent's list of known subxacts; this leaves the parent's nsubxacts * count too high, but we don't care. Otherwise, we are deleting the TXN * from the LSN-ordered list of toplevel TXNs. */ dlist_delete(&txn->node);
      
      





ディスカッション: 20160404190345.54d84ee8@fujitsu

コミット: b6182081be4a795d70b966be2542ad32d1ffbc20



2.変数の二重初期化の修正



正直なところ、この問題が目で見つかったのか、静的アナライザーで見つかったのかは覚えていません。 いくつかの場所で、スタイルのコードが発見されました。



 char *qual_value; ParseState *qual_pstate = make_parsestate(NULL); /* parsestate is built just to build the range table */ qual_pstate = make_parsestate(NULL);
      
      





ご覧のとおり、変数はプロセッサを無駄に温めている場合にのみ2回初期化されます。 パッチは、特別な質問なしに即座に受け入れられました。



ディスカッション: 20160316112019.64057481@fujitsu

コミット: bd0ab28912d7502b237b8aeb95d052abe4ff6bc6



3.コメントのタイプミスの修正



かなり大きなプロジェクトでは、かなりのタイプミスがあります。 IDEまたはテキストエディタでスペルチェックを有効にすることで、それらを見つけるのは非常に簡単です。 私は個人的にVimでコードを書いています 。 〜/ .vimrcのスペルをチェックするには、次の行があります。



 command! SpellOn :set spell spelllang=en_us,ru_ru command! SpellOff :set nospell
      
      





誰もが興味を持っている場合、他のすべての構成ファイルと同様に、私の〜/ .vimrcの完全版はこちらから入手できます



多くの場合、パッチを受け入れる前に、コミッターがそれらを少し、非常にわずかに書き換えるという理由で、タイプミスが現れます。 その結果、これまで誰も読んだことのないまったく新しいコードができました。 新しいコミットを注意深く読み、タイプミスを見つけるだけで、毎週いくつかのパッチを送信できます!



ディスカッション:( 何かが見つかりません)

コミット: 2d8a1e22b109680204cb015a30e5a733a233ed64



4. 2つの同一のコメントの修正



コメントのタイプミスに加えて、他のタイプのエラーがあります。 たとえば、 b6fb6471 commitの結果として、 のコードが追加されました。



 /*----------- * pgstat_progress_update_param() - * * Update index'th member in st_progress_param[] of own backend entry. *----------- */ void pgstat_progress_update_param(int index, int64 val) { volatile PgBackendStatus *beentry = MyBEEntry; Assert(index >= 0 && index < PGSTAT_NUM_PROGRESS_PARAM); if (!beentry || !pgstat_track_activities) return; pgstat_increment_changecount_before(beentry); beentry->st_progress_param[index] = val; pgstat_increment_changecount_after(beentry); } /*----------- * pgstat_progress_end_command() - * * Update index'th member in st_progress_param[] of own backend entry. *----------- */ void pgstat_progress_end_command(void) {
      
      





2つの異なる手順の説明がまったく同じであることがわかります。これは明らかにある種のわき柱です。



ディスカッション: 20160310120506.5007ea28@fujitsu

コミット: 090b287fc59e7a44da8c3e0823eecdc8ea4522f2



5. FreeBSDでのコンパイル時の問題



ほとんどのPostgreSQL開発者はMacOSとLinuxの下に座っています。 したがって、Microsoft Windows :)やFreeBSDなどのエキゾチックなプロジェクトをビルドしようとすると便利です。 たとえば、このトリックを使用すると、FreeBSD上のPostgreSQLで次の警告が表示されることがわかりました。



 pg_locale.c:1290:12: warning: implicit declaration of function 'wcstombs_l' is invalid in C99 [-Wimplicit-function-declaration] result = wcstombs_l(to, from, tolen, locale); pg_locale.c:1365:13: warning: implicit declaration of function 'mbstowcs_l' is invalid in C99 [-Wimplicit-function-declaration] result = mbstowcs_l(to, str, tolen, locale); 2 warnings generated.
      
      





この問題を修正するのはそれほど難しいことではありませんでしたが、Autotoolsいじる必要がありました。



ディスカッション: 20160310163632.53d8e2cc@fujitsu

コミット: 0e9b89986b7ced6daffdf14638a25a35c45423ff



続行するには...



ご覧のとおり、PostgreSQLへの貢献を開始するには、リレーショナルデータベースデバイスの深い知識やCでの10年のプログラミング経験は必要ありません。概して、理論的には誰でも貢献者になることができます。 この部分では、おそらく最も些細なパッチが検討されました。 次回は、ロック競合の問題を解決し、アルゴリズムの複雑さをO(N)からO(1)に減らし、バイナリツリートラバーサルを実装し、リソースリークを修復する、より興味深いパッチを見ていきます。



いつものように、私はあなたのコメントや質問に喜んでいます!



続き: PostgreSQLの実際のパッチの例:Nのパート2



All Articles