PostgreSQLの実際のパッチの例：Nのパート2

以前の記事では、PostgreSQLの開発プロセスと 、このRDBMSで最近採用された実際のパッチの例を見てきました 。 同時に、考慮されたパッチは、率直に言って、「軽薄」なものでした-タイプミスの修正、静的分析を使用して見つかった最も単純な妨害の修正などです。

今日は、すでに深刻なパッチの例を見て、コードのボトルネックを解消し、かなり深刻なバグを修正し、比較的大きなリファクタリングなどを行います。 以前と同様に、この記事の主な目的は、PostgreSQL 9.6で採用された変更を強調することではなく、オープンソースプロジェクト、特にPostgreSQLの開発が興味深く、あなたにとってはそれほど難しくないことを示すことです。

このトピックに興味がある場合は、猫をお願いします。

6.多数のリソースに対するResourceOwnerの高速化

ResourceOwnerは、SQLクエリの実行プロセスでリソースを管理するように設計されたオブジェクトです（「オブジェクト」という単語が手続き型言語Cに適用される限り）。 トランザクションとサブトランザクションごとに個別のResourceOwnerが作成されます。 ResourceOwnerには、RememberLock / ForgetLock、RememberFile / ForgetFileなどの多くのメソッドがあります。 さらに、ResourceOwnersは階層化できます。 何らかの理由でトランザクションのロールバックが発生した場合（ユーザーがロールバック、例外が発生したなど）、ResourceOwnerを単にリリースします。このリリースにより、このResourceOwnerで使用されているすべてのリソースが解放されます。彼の「子供」。 詳細は、 対応するREADMEファイルに記載されています 。

9.5では、ResourceOwnerは配列を使用してリソースを保存しました。 通常、リソースは割り当てられた順序と逆の順序で解放されると想定されていたため、Forget *メソッドは配列の最後からリソースを探しました。 しかし、実際には、このアプローチは必ずしもうまく機能しないことが判明しました。 したがって、 プロファイリングは 、このアプローチで多数のパーティションを持つテーブルに対して最も単純なSELECTクエリを実行すると、PostgreSQLはこれらの同じForget *メソッドですべての時間の30％を費やすことを示しました。

配列をハッシュテーブルに置き換えることで、ボトルネックを解消することができました。 さらに、ResourceOwnerのリソースの量が少ない場合、以前と同様に配列が使用されます。

/* * ResourceArray is a common structure for storing all types of resource IDs. * * We manage small sets of resource IDs by keeping them in a simple array: * itemsarr[k] holds an ID, for 0 <= k < nitems <= maxitems = capacity. * * If a set grows large, we switch over to using open-addressing hashing. * Then, itemsarr[] is a hash table of "capacity" slots, with each * slot holding either an ID or "invalidval". nitems is the number of valid * items present; if it would exceed maxitems, we enlarge the array and * re-hash. In this mode, maxitems should be rather less than capacity so * that we don't waste too much time searching for empty slots. * * In either mode, lastidx remembers the location of the last item inserted * or returned by GetAny; this speeds up searches in ResourceArrayRemove. */ typedef struct ResourceArray { Datum *itemsarr; /* buffer for storing values */ Datum invalidval; /* value that is considered invalid */ uint32 capacity; /* allocated length of itemsarr[] */ uint32 nitems; /* how many items are stored in items array */ uint32 maxitems; /* current limit on nitems before enlarging */ uint32 lastidx; /* index of last item returned by GetAny */ } ResourceArray; 

同じパッチにはResourceOwnerリファクタリングが含まれています。 以前は、リソースのタイプごとに、Files、HeapTuplesなどの個別の配列が使用されていました。 これらの型はすべてポインターまたは整数であるため、Datum（uintptr_tのローカル対応）に格納できます。 新しいResourceArrayエンティティが導入されました。これにより、リソースを保存できるようになり、大量の重複コードが排除されました。

コミット： cc988fbb0bf60a83b628b5615e6bade5ae9ae6f4
ディスカッション： 20151204151504.5c7e4278@fujitsu

7.共有ダイナハッシュのパーティショニングフリーリスト

Dynahash（ dynahash.cファイルを参照）は、ハッシュテーブルのローカル実装です。 PostgreSQLハッシュテーブルは、作成されたフラグによって非常に異なる動作をする可能性があります。 たとえば、ローカルプロセスメモリと共有メモリの両方に存在できます 。 後者を使用する場合、共有メモリはすべてのPostgreSQLプロセスの同じ仮想アドレスにマップされます。 共有メモリは一度割り当てられ、このメモリの量はRDBMSの操作中に変更できません。

これらの理由から、いわゆるフリーリストを使用して、共有ハッシュテーブルの空きメモリ（空きメモリの小さな断片のリスト）を追跡します。 メモリを解放すると、空きリストに追加されます。 メモリを割り当てる必要がある場合、空きリストから取得されます。 共有ハッシュテーブルへのアクセスは一度に複数のプロセスによって実行されるため、フリーリストへのアクセスはスピンロックを使用して同期されます。 特定のロードがこのスピンロックのロック競合を引き起こすことが判明しました。

結果のパッチは、この問題を次のように解決します。 1つのフリーリストの代わりに、いくつかの（32）が使用され、それぞれに独自のスピンロックがあります。

それは：

  struct HASHHDR { slock_t mutex; /* unused if not partitioned table */ long nentries; /* number of entries in hash table */ HASHELEMENT *freeList; /* linked list of free elements */ /* ... */ 

次のようになりました：

 #define NUM_FREELISTS 32 typedef struct { slock_t mutex; /* spinlock */ long nentries; /* number of entries */ HASHELEMENT *freeList; /* list of free elements */ } FreeListData; struct HASHHDR { FreeListData freeList[NUM_FREELISTS]; /* ... */ 

デフォルトでは、空きリストはメモリの割り当てに使用され、その数はキーからのハッシュ値の下位ビットによって決定されます。

 #define FREELIST_IDX(hctl, hashcode) \ (IS_PARTITIONED(hctl) ? hashcode % NUM_FREELISTS : 0) 

ただし、「私たちの」フリーリストのメモリがなくなると、他のフリーリストから「借用」されます。

とりわけ、このパッチは、採用前に約15のバージョンを作成し、フリーリスト、その数、およびその他のパラメーターの可能なすべてのシャーディング戦略を実際にソートし、最高のパフォーマンスを示した1つのオプションを選択する必要がありました。 たとえば、最終実装で使用される32個のスピンロックの代わりに、1つのRWLockを使用できます。RWLockは、「私たちの」フリーリストからメモリを取得する場合は読み取り用、他から借りる場合は記録用にキャプチャされます。 さらに、スピンロックは、キャッシュラインの配置の有無にかかわらず、メモリ内でさまざまな方法で配置できます。

コミット： 44ca4022f3f9297bab5cbffdd97973dbba1879ed
ディスカッション： 20151211170001.78ded9d7@fujitsu

8. RBツリーでの複数のイテレーターのサポート

別の機能に取り組んでいるときに、PostgreSQLの赤黒ツリー（現在はGINインデックスでのみ使用されています）の反復インターフェイスが次のようになっていることに気付きました。

 void rb_begin_iterate(RBTree *rb, RBOrderControl ctrl); RBNode *rb_iterate(RBTree *rb); 

このインターフェイスでは、ツリー内に複数のイテレータを作成できないため、かなり不便です。 さらに、実装は非常に奇妙でした。 たとえば、彼女はツリーのノードに反復状態を保存しました。

少し考えて、この経済をすべて書き直した後、インターフェースは次のようになりました。

 void rb_begin_iterate(RBTree *rb, RBOrderControl ctrl, RBTreeIterator *iter); RBNode *rb_iterate(RBTreeIterator *iter); 

PostgreSQLで使用されるさまざまなコンテナの詳細については、 Cリストと検索ツリーに関する単調な記事ではありません 。 さらに、このタスクに取り組む過程で作成したGitHubリポジトリに興味があるかもしれません。 その中には、Cの単一および二重リンクリスト、赤黒ツリー、ハッシュテーブルの実装があります。ライブラリは、テストで十分にカバーされ、MIT / BSDライセンスの下で配布されています。

コミット： 9f85784cae4d057f307b83b0d33edede33434f04
ディスカッション： 20160727172645.3180b2e0@fujitsu

9.いくつかのセグメントを持つテーブルのpg_filedumpのチェックサムの検証の修正

PostgreSQLは、テーブルとインデックスのデータをいわゆるページに保存します。 1ページのデフォルトサイズは8 Kbです。 ページは、セグメントと呼ばれるディスク上のファイルに保存されます。 1つのセグメントのサイズはデフォルトで1 GBです。 関係とインデックスをセグメントに切断すると、PostgreSQLは1 GBを超えるファイルをサポートしないファイルシステムでも動作します。 ページを使用して、メモリ内の頻繁に使用されるデータのキャッシュは、いわゆるバッファマネージャによって実装され、ディスクアクセスの数が大幅に削減されます。

pg_filedumpユーティリティを使用すると、セグメントとページでさまざまな便利なことができます。 たとえば、彼女はセグメント内のすべてのページのチェックサムをチェックできます。 データベースが-kフラグを指定してinitdbを呼び出して作成された場合、チェックサムはページに書き込まれます。

  -k, --data-checksums use data page checksums 

興味深いことに、ページのハッシュ関数を計算するpg_checksum_pageプロシージャは、ページのコンテンツだけでなくブロック番号にも依存します。

 uint16 pg_checksum_page(char *page, BlockNumber blkno) 

これにより、ページに正しいデータが保存されるだけでなく、セグメント内の正しいオフセットに記録されることを確認できます。

そのため、最近、pg_filedumpでバグが発見されました。 ゼロセグメントのチェックサムは正しくチェックされましたが、1番目、2番目などのセグメントでは、pg_filedumpによって読み取られたチェックサムは、PostgreSQL自体によって計算されたチェックサムと一致しませんでした。 結局のところ、pg_filedumpはどのセグメントでもブロック番号をゼロからカウントし始めました。 正しい方法は、以前のすべてのセグメントを考慮し、「相対的な」ものではなく、このセグメントに「絶対的な」ブログ番号を使用することです。

明らかな理由により、同じパッチで、pg_filedumpに以前は欠落していた2つのフラグのサポートが追加されました。

  -s Force segment size to [segsize] -n Force segment number to [segnumber] 

コミット： 052ed0112967dd1e9b0e2cbe54821c04475f1a3a
ディスカッション：（ 排他的にオフリスト）

10. malloc（）、realloc（）、およびその他のプロシージャによって返される値を確認する

結局、私は自分ではなく、レビュアーとして行動するパッチを書いて残すことにしました。 コードレビューの過程で、このパッチの多くの改善を提案しました。

Michael Paquierは、PostgreSQLがmalloc（）、realloc（）、およびstrdup（）プロシージャのリターンコードをチェックしない場所があるという事実に注目しました。 パッチの作業中に、プロシージャのリストはcalloc（）で補完され、共有メモリを操作するためのプロシージャも追加されました。

その結果、可能な場合、呼び出しは同様の安全なPostgreSQLの類似物（pg_strdup、pg_mallocなど）に置き換えられました。

 - steps = malloc(sizeof(Step *) * nsteps); + steps = pg_malloc(sizeof(Step *) * nsteps); 

他の場所では、チェックが単に追加されました。

  new_environ = (char **) malloc((i + 1) * sizeof(char *)); + if (!new_environ) + { + write_stderr("out of memory\n"); + exit(1); + } 

マイケル自身の投稿-Postgres 10ハイライト-ShmemAllocおよびShmemAllocNoErrorも参照してください。

コミット： 052cc223、6c03d981
ディスカッション： CAB7nPqRu07Ot6iht9i9KRfYLpDaF2ZuUv5y_+72uP23ZAGysRg@mail.gmail.com

続行するには...

もちろん、そのような投稿が誰かに興味があるという条件で:)おそらく、同僚の1人に最近作業したパッチをカバーするように説得することもできるでしょう。 結局のところ、この更新プログラムの開発者よりも、この更新プログラムについて誰がよりよく知ることができますか？

いつものように、私はあなたの質問を楽しみにしており、コメントでそれらに答えたいです。 そして一般的に、コメントや追加をためらわないでください！

続き： PostgreSQLの実際のパッチの例：Nのパート3