pg_waldumpのように出力を一度に吐き出すのではなく、ターミナル上でカーソルを動かしながらWALレコードを1つずつ眺めていくツールです。Rustで書いています。
pg_waldumpは-xでXID、-rでリソースマネージャ、-Rや-Bでリレーションやブロック、という具合に絞り込みは一通りできます。ですが、絞り込むと今度はその前後で何が起きていたかが見えなくなります。-xを付けて実行して、やっぱり周りが気になって-xを外して実行して、というのを何度も繰り返していました。だったら全部読み込んでおいて、その場で視点だけ切り替えられればいいのでは、と思ったのがきっかけです。
画面は3つのペインに分かれていて、Tabでフォーカスを移動します。
LSN、XID、レコード長、FPIの有無、リソースマネージャ、説明の一覧です。
一番やりたかったのが左端のグラフ線です。カーソルを合わせたレコードと同じXIDを持つレコードが、線で繋がって表示されます。
0/100 13840 171 Heap UPDATE
┏━ 0/100 13841 8135 Heap LOCK ← このXIDの最初のレコード
┃ 0/100 13839 8135 Heap LOCK
┣━ 0/100 13841 171 Heap UPDATE ← カーソル位置
┃ 0/100 13840 8135 Heap LOCK
┃ 0/100 13839 171 Heap UPDATE
┣━ 0/100 13841 64 Btree INSERT_LEAF
┗━ 0/100 13841 34 Transact COMMIT ← このXIDの最後のレコード
他のトランザクションのレコードは間に挟まったまま残ります。なので、絞り込まずに特定のトランザクションだけを目で追えます。sとrで同じXIDの次／前のレコードにジャンプすることもできます1。
線の色は、そのXIDの最後のレコードを見て決めています。要はそのトランザクションがどう終わったかです。
| 状態 | 判定条件 |
|---|---|
| コミット済み | COMMIT または COMMIT_PREPARED で終わっている |
| アボート | ABORT または ABORT_PREPARED で終わっている |
| 保留中 | PREPARE など、コミットでもアボートでもないTransactionレコードで終わっている |
| 未完結 | Transactionレコードで終わっていない |
最後の「未完結」が地味に便利です。そのトランザクションがこのWALファイル内では完結していない、つまり続きが次のセグメントにあるということなので、次のファイルを開くべきかどうかがわかります。
ちなみに使っているのはANSIの16色だけです。実際にどう見えるかは端末のテーマ次第。NO_COLORを設定すれば色は落ちます。
選択中のレコードの詳細です。XLogRecordのヘッダ、ブロック参照（RelFileLocator、フォーク、ブロック番号、フラグ）、そしてリソースマネージャごとにデコードした構造体のフィールドが並びます。
アコーディオンになっていて、Enterでブロックごとの詳細を開閉できます。HeapのUPDATEならxl_heap_headerのt_infomaskやt_infomask2をフラグ名に展開して表示します。HEAP_XMAX_INVALIDが立っているかどうか、みたいな確認をその場でできるので便利です。
WALセグメント全体のバイト列です。各行はLSNとファイルオフセットの両方で位置を示すので、レコードがどのページのどこに載っているかを見ながら読めます。
色が付くのは選択中のレコードのバイトだけです。しかもXLogRecordのヘッダ、ディスクリプタ、FPI、ブロックデータ、メインデータ、と構造ごとに色が分かれます。ページ境界をまたぐレコードは、実際にファイル上で占めている複数の断片として色が付きます。間に挟まるページヘッダはレコードの一部ではないので、そこには色を付けていません。
DETAILSでカーソルを合わせている項目は、ダンプ側でも強調されます。なのでアコーディオンがそのままバイト列のナビゲータになります。デコード結果と生バイトを並べて見られるのは、*desc.c相当の実装2を書いているときのデバッグにも効きました。
pg_configにパスが通っていればそのままビルドできます。ビルド時にPostgreSQL本体のヘッダからXLogRecordなどの定義を取り込んでいるので、ヘッダが必要です3。
git clone https://github.com/MasahikoSawada/pg_walview.git
cd pg_walview
cargo build --release
# PostgreSQLを独自の場所にインストールしている場合
PG_INCLUDE_DIR=/path/to/pgsql/include/server cargo build --release
あとはWALファイルのパスを渡すだけです。サーバに接続するわけではないので、稼働中のインスタンスでなくても、コピーしてきたWALファイルさえあれば読めます。
pg_walview /path/to/pg_wal/000000010000000000000001
主なキーバインドはこちら。
| キー | 動作 |
|---|---|
j / k |
次／前のレコードへ移動 |
g / G |
最初／最後のレコードへ移動 |
s / r |
同じXIDの次／前のレコードへジャンプ |
Space / - |
ページ送り／ページ戻し |
Tab |
ペインの切り替え |
q |
終了 |
--wal-segsizeを大きくしている環境では効いてくるかもしれません。なおセグメントサイズ自体はロングページヘッダから読むので、非デフォルトでも読めますWALの中身を見る手段としてはpg_waldumpもpg_walinspectもありますし、機能面では当然そちらのほうが揃っています。pg_walviewは「対話的に動き回れる」という一点だけに絞ったツールです。
自分の場合、ロジカルレプリケーション関連のデバッグで、このトランザクションはどこでコミットされたのか、このレコードとこのレコードの間に何が挟まっているのか、といったことを追う機会が多くあります。その用途では作ってよかったと思っています。
ソースはGitHubに置いてあります。MITライセンスです。ContributionもWelcomeです！
ただしXIDが0、1、2のときはジャンプを無効にしています。それぞれInvalidTransactionId、BootstrapTransactionId、FrozenTransactionIdですが、XIDを持たないレコードは大量にあるので、繋いでも意味がないためです。 ↩
リソースマネージャごとのデコード部分は、PostgreSQL本体のsrc/backend/access/rmgrdesc/にある*desc.cと同じ役割です。本体の構造に寄せておいたほうが、あとで追従しやすいはず、という判断でそうしています。 ↩
なので、ビルドしたヘッダのバージョンのWALしか読めません。別バージョンのセグメントを開いた場合は、誤読せずにページマジックの不一致としてエラーになります。--versionを付けると、そのバイナリがどのPostgreSQL向けにビルドされたものかを表示します。 ↩
まずは自分の簡単なバックグランドから：
学部生時代は、大学院の選択肢は自分の中に全くありませんでした。大学院に進んで勉強したことは当時の自分にはありませんでしたし、「第一希望の就職先から内定をもらったし早く働き始めたい」と考えていたからです。
就職してしばらくした頃に、オンラインでアメリカの大学院に通うことができると知り興味を持ちました。ですが、英語が壊滅的にできなかったため(大学卒業時に受けたTOEICは300点でした)、TOEFLの基準を満たすための準備が大変で、モチベーションが上がってはTOEFL対策をし、でも途中で他のことに興味が出てきて中断する、を何年も繰り返していました。そうこうしているうちに、12年以上のデータベース一本のキャリアが出来上がっていました。データベースという一つの強みを持てたのと同時に、他の分野も他の分野も学んでみたいという気持ちが強くなってきました。キャリアの幅を広げるきっかけになると良いなとも思いましたし、色々な方向に知見を一度広げてからデータベース業界に戻ってくることも自分を成長させるうえで魅力的な選択肢だと思いました。
様々な学校を検討しましたが、私が重視した点は以下の通りです：
学部生時代の成績は専門科目であれば平均でGPA 3.9くらい(全体で3.7くらい)だったのでクリアしていました。
一方で、Algorithms and Complexity (CS331)に相当する科目は履修していなかったり、学部生時代に履修した科目では微妙にカバーしきれていない点は懸念でした。しかし、PostgreSQLの開発において、Vacuumや論理レプリケーションの最適化をする際に、色々なデータ構造やアルゴリズムの比較を行った実績を具体的に記述することで、「アカデミックな単位はないが、実務レベルで同等の知識はある」とアピールしました。
TOEFL対策は色々試したのですがどれも続かず、その間にTOEFLの試験内容も変わっていってしまいとても苦戦しました。未だに自分にあった学習方法やリソースが見つけられていません。自分の実力を測ってみようと久しぶりにTOEFLを受けてみたら基準点を超えていました。実務で英語を使っていたおかげで、自分でも気づかないうちに力がついていたのかもしれません。また、TOEFLの基準点は79点以上(またはIELTS 6.5以上)なので、他のCSオンライン修士コースよりも低めです。
業務では英語を使いながら少しずつ上達しています。まずは自分の今の実力を知ろうと、久しぶりにTOEFLを受けてみたら運よく基準点を超えていました。
ChatGPTを壁打ち相手に使いながら、これまでの実績をアピールしつつ、なぜUT Austinに入りたいのか、そしてUT Austinで得る経験を将来にどうつなげたいのかを書きました。自分の場合は、PostgreSQLにAdaptive Radix Treeを実装した経験を通してデータ構造や仕組みを理論から理解することの重要性を感じた事、そして、経験則だけでなく、体系的なコンピュータサイエンス（CS）の理論を学ぶことで、アカデミアの研究と産業界の実装を両方がわかる人になりたい（アカデミアにも還元していきたい）、といった旨を書きました。
1月から始まった春学期では、以前から取りたかった理論系の科目「Automated Logical Reasoning」を履修しています。この授業をやりきった後、データベースの見え方が少し変わったり、何か新しいアイデアが生まれたりするかもしれないと思うと、今からとても楽しみです。
英語へのコンプレックスや、10年以上のブランク、そして仕事・育児との両立など、不安要素は数え切れないほどありましたが、一歩踏み出してみて本当によかったと感じています。まだ始まったばかりですが、「理論を学びたい」という初心を忘れず、卒業目指して地道に頑張っていこうと思います。興味があればぜひ海外大学院のオンラインコースに出願してみてください。また、質問があればDMください。
]]>2025年9月にリリースされたPostgreSQL 18も、現在開発中のPostgreSQL 19もLogical Replication関連の開発がメインだった。自分が開発した機能では、wal_levelのreplicaとlogicalを再起動なしで自動的に切り替えるようになる機能の開発に一番時間を割いたと思う(67c20979ce7)。他にも、update_deletedコンフリクトを確実に検出するための機能(228c3708685)や、Logical Replicationにシーケンスを対応させる機能(5509055d695、f0b3573c3aa、96b37849734)はレビュアーとして参画した。
あとは、CPUアーキテクチャによってcharの符号が異なることが原因でGINインデックスのスキャン結果が変わってしまう問題を直せたのも良かったし(dfd8e6c73ee, 1aab6805919, a8238f87f98, 30666d1857d, 44fe30fdab6)、CVEのバグ修正のレビューに参加できたのも良い経験となった627acc3caa7。
2025年では62件コミットできたようだ:
$ git log --author "Masahiko Sawada" --since=2025-01-01 --oneline | wc -l
62
来年は100件以上を目指そう。
PGConf.dev 2025では「The Present and Future of VACUUM of PostgreSQL」という発表をした(スライド、動画)。また、Advanced Patch Feedback Sessionというセッションにも参加して、対面でパッチについて議論しながら、開発が先に進めるようにコミッタ視点でアドバイスをする、ということもしてきた。その他にも、Code Of Conduct Committeeのメンバに入れてもらえたり、Lightning Talksの運営をやったりと、運営側としても参加できたカンファレンスだった。
PostgreSQLコミュニティでは、hacker mentoring programというのがあり、PostgreSQL Committerが希望者に付いて一緒に開発したりアドバイスをする取り組みがある。今年は自分もCommitterとして参加して、1人メンティーを持つことになった。
また、PostgreSQLの開発に興味があるけどやり方が分からなず参加できない、という人のために個人的になにかできることはないかと考えXで募集してみた。
PostgreSQLのLogical Replicationの改善に興味がある人いないかな。簡単なバックログもあるので未経験でもアドバイスしながら一緒にPostgreSQL開発を経験できます。
— Masahiko Sawada (@masahiko_sawada) October 14, 2025
すると、9人も興味を示していただき、1人1時間ほどのハンズオンを通して、PostgreSQL開発コミュニティの事やソースコードの構成など説明したり、私の方で用意したパッチネタについて議論するなどをした。参加いただいた方々の満足度はわからないが、そのハンズオン以降、2名の方がめでたくPostgreSQL Contributorとなった(リリースノートに名前が載ります)。その後、日本以外の方からも連絡をもらったりしたのですが、中々自分の時間が取れず現在は一旦休止しています。
Rustの勉強を始めた。並行してRust製のOSSを使うことも始めたいな色々と探していたらRust製でbash/POSIX互換を謳っているbrushという良さげなシェルがあったので、これを使い始めた。Tab補完周りでバグを見つけたのでIssueとPRを出したらめでたくMergeしてもらい、Rust製OSSへのContributionを経験できた。他にもいくつか見つけた問題があるのでこれからもContributionを続けていきたい。
あとは、Rustのコンパイラ(rustc)にも興味があり、ソースコードや関連する資料を見始めた。
2025年9月からテキサス大学(UT Austin)のCS修士課程(オンライン)を始めてみました。オンラインCS修士課程だと一番有名なのはジョージア工科大学のOMSCSですが、UT Austinでも比較的低価格で受けることができます。CS修士課程ではあるのですが、どちらからというと理論や数学系の勉強をしたかったのでUT Austinのコースを取りました。実際やってみると体力的に1学期1授業が限界な感じ。
2024年からアメリカに住み始めたので今年は(一時帰国した7月を除くと)ほぼ1年丸々アメリカにいたことになります。仕事の内容は渡米前後で変わらないので良くも悪くも変化無し。開発チームとタイムゾーンが一緒になれたのは一番良かったことの一つかもしれない。突然やってくるレイオフの波、物価高、たまにニュースで見る危ない事件などに怯えることもありますが、キャンプやったりバーベキューやったりしてなんだかんだ楽しくやっています。来年にH1-Bに切り替えられるのでちょっとは安心かも（それまでにレイオフに合わなければ）。
Logical Replication周りはまだまだ改善点が多いので引き続き開発していきます。
]]>物理レプリケーションと論理レプリケーションの性能を比較するために、色々実験をしていたら少し嵌ってしまったのでその備忘録です。
実験では、トランザクションがCommitされてからそれが受信側で適用するまでの時間を計測しました。具体的には、同期レプリケーションを利用し、synchronous_commitを変更しながらトランザクションの完了時間を比較します。synchronous_commitパラメータを使うと「何を持って受信側で変更の適用が完了したとみなすか」(例えば、メモリ上に書かれた時点で完了とするなど)をトランザクション単位で制御することができますす。発生させたトランザクションは、1000行INSERTするような軽いトランザクションです。
結果はこちら:
| remote_write | on | remote_apply | |
|---|---|---|---|
| 物理レプリケーション | 2.551 ms | 3.858 ms | 4.788 ms |
| 論理レプリケーション | 5.744 ms | 405.534 ms | 5.377 ms |
物理レプリケーションの結果は想定通りでした。スタンバイで適用をより待つようにsynchronous_commitを設定する(remote_write -> on -> remote_apply)と、トランザクション完了までより長い時間がかかります。
一方、論理レプリケーションでは、実行時間がon > remote_applyであり、onの時にかなり長い時間がかかっている結果となり、ちょっと意外でした。
物理レプリケーション、論理レプリケーションは基本的には似たように動いているはずなので、適用完了とみなしたLSNがどのように管理されているのかを調査しました。それらはpg_stat_replicationビューのsent_lsn、write_lsn、flush_lsn、replay_lsn列の値に対応します。sent_lsn、write_lsn、flush_lsn、replay_lsnは、どこまでの変更を送信完了なのかやどこまでの変更が複製完了なのかを示すLSN（Log Sequence Number）です。これらは、レプリケーションのラグを計測するのにとても便利で、例えば、pg_current_wal_lsn() - sent_lsnを計算することで、どれくらい変更の送信が遅れているのかがわかります。`
それぞれの列の値はどのようにこうしんされるのでしょうか。
物理レプリケーションの場合は、プライマリはWALが書かれた順番通りに送り、スタンバイはそれを適用するので単純です。
sent_lsnを更新）write_lsnを更新）flush_lsnを更新）replay_lsnを更新）プライマリに通知する各LSNは以下の通りになります:
pg_stat_replicationビューでのそれぞれの列値は、sent_lsn -> write_lsn -> flush_lsn -> replay_lsnの順に増えていきます。
論理レプリケーションでは、パブリッシャ（送信側）はWALをデコードし、コミット順に並び替えてからトランザクション単位で送り、サブスクライバ（受信側）ではトランザクション単位で適用するので多少複雑です。サブスクライバでは、「パブリッシャで発生したトランザクションのCommit LSN1」と「それをローカルで適用して得られたCommit LSN」をペアで管理します。例えば、パブリッシャで3つのトランザクションが発生し、それぞれのCommit LSNが100, 120, 200だった場合、それぞれのトランザクションをサブスクライバで適用して、以下のようにCommit LSNのペアを管理します：
{remote commit-lsn = 100, local commit-lsn = 123}
{remote commit-lsn = 120, local commit-lsn = 1234}
{remote commit-lsn = 200, local commit-lsn = 2345}
サブスクライバがどこまでのWALを適用したのかをパブリッシャへ通知する際は、上記の情報を元に「どのトランザクションまでをCommitしたのか」、「どのトランザクションまでをCommitしそのWALをFlushしたのか」を計算します。例えば、サブスクライバでの最新のFlush済みLSNが2000だった場合、remote commit-lsn = 120まではCommitが完了しており、remote commit-lsn = 200はCommit済みだけどまだFlushされていない、という事になります。パブリッシャに通知するLSNは、
つまり、物理レプリケーションとは違い、データを受信(write)→それを適用(replay)→適用したWALをFlushという流れて処理するので、pg_stat_replicationビューでのそれぞれの列値は、sent_lsn -> write_lsn -> replay_lsn -> flush_lsnの順に増えていきます。
ソースコードやドキュメントを確認していると、サブスクライバでパブリッシャからの変更を受け取り適用するワーカー（Apply Worker）はデフォルトでは非同期コミットを利用していることがわかりました。つまり、先程の実験でサブスクライバでは、Apply Workerが変更を適用することで発生したWALレコードを、WAL WriterプロセスがFlushするまで待つ必要があった訳です。その遅延は最大でwal_writer_delayの3倍で、wal_writer_delayはデフォルトで200msです。
実際にwal_writer_delay = 10msに変更するとsynchronous_commit = onでの結果が変わりました:
| remote_write | on | remote_apply | |
|---|---|---|---|
| 論理レプリケーション(wal_writer_delay = 200ms) | 5.744 ms | 405.534 ms | 5.377 ms |
| 論理レプリケーション(wal_writer_delay = 10ms) | 5.352 ms | 26.813 ms | 5.289 ms |
wal_writer_delayを変更してより早くWALをFlushすることで待ち時間を少なくする代わりに、CREATE SUBSCRIPTIONに用意されているsynchronous_commitオプションを利用することも可能です。ドキュメントにもしっかり書かれています:
同期論理レプリケーションを行う場合は別の設定が適切かもしれません。 論理レプリケーションのワーカーは書き込みおよび吐き出しの位置をパブリッシャーに報告しますが、同期レプリケーションを行っているときは、パブリッシャーは実際に吐き出しがされるのを待ちます。 これはつまり、サブスクリプションが同期レプリケーションで使われている時に、サブスクライバーのsynchronous_commitをoffに設定すると、パブリッシャーでのCOMMITの遅延が増大するかもしれない、ということを意味します。 この場合、synchronous_commitをlocalまたはそれ以上に設定することが有利になりえます。
試してみると:
| remote_write | on | remote_apply | |
|---|---|---|---|
| 論理レプリケーション(synchronous_commitオプション = off) | 5.744 ms | 405.534 ms | 5.377 ms |
| 論理レプリケーション(synchronous_commitオプション = on) | 5.829 ms | 5.851 ms | 5.874 ms |
という感じで納得行く結果を得ることができました。wal_writer_delayはインスタンス全体に影響を与えてしまうので、synchronous_commitオプションで調整するの方が推奨です。
最初からドキュメントを読んでいればよかったですが、調査を通して論理レプリケーションのflush_lsnとreplay_lsn更新の仕方の違いなども知ることができたので良かったです。次回は、本来やりたかった物理レプリケーションと論理レプリケーションの性能比較をやっていきます。
トランザクションのCommit WALレコードのLSN ↩
UUIDの生成速度が気になったきっかけは、PostgreSQLで色々なUUIDv7生成方法を比較していた時に、PostgreSQL 18で導入される予定のuuidv7()関数とpgrxで自前で作ったUUIDv7生成関数の性能比較をしていたときでした。
PostgreSQL 18のuuidv7()関数はC言語で実装されていて、自作のpgrxのUUIDv7（便宜上pgrx_uuiv7()と呼びます）はRustのuuid createを利用して実装しています1。
UUIDv7を100万件生成するのにかかった時間は以下のとおりです:
| uuidv7() | pgrx_uuidv7() | |
|---|---|---|
| 実行時間(ms) | 2203.124 | 264.688 |
uuidv7()でも秒間約45万個のUUIDv7が生成できていてる一方で、pgrx_uuidv7()は約10倍近く速い結果となりました。この生成速度の違いを調べた所、ランダムデータ生成が実行時間の大半を占めていて、それぞれの方式で異なるランダムデータ生成方法が使用されていることがわかりました。
PostgreSQLは以下の2つ種類のランダムデータ生成方法をサポートしています（Linuxの場合）：
RAND_bytes()関数を使うPostgreSQLではビルド時にどちらの方法を利用するか決めていて、OpenSSLを利用してビルドした場合(--with-opensslを指定)は常に1を選択することになります。2はFallBackとして用意されています。
先程の性能測定では、OpenSSLを利用しないでビルドしたPostgreSQLを利用したので2の方法を利用していました。2はコードを見ると分かる通り、/dev/urandomをopen()してread()し、最後にclose()するという、移植性の高い方法ではありますが性能的には良くありません。
一方、OpenSSLを利用するとRAND_bytes()関数を使用してランダムデータを生成します。PostgreSQLをOpenSSLを有効にしてビルドし直してもう一度UUIDv7の生成速度を測定してます。
| uuidv7() (/dev/urandomを利用) | uuidv7() (OpenSSLのRAND_bytes()を利用) | pgrx_uuidv7() | |
|---|---|---|---|
| 実行時間(ms) | 2203.124 | 759.296 | 264.688 |
OpenSSLは/dev/urandomよりはかなり速いが、pgrx_uuidv7()よりは遅いという結果になりました。世の中のほぼすべてのPostgreSQLはOpenSSLを有効にしてビルドされたものだと思うので、UUIDの生成速度で困ることはほとんどないでしょう。
しかし、pgrx_uuidv7()とはまだ3倍近くの差があります。一度検証を始めたからには、この差を埋める方法が見つかるまでさらに検証を進めていきます。
getrandom()を使っていたpgrx_uuidv()の元になっているUuid::now_v7()を調べた所、おそらく最終的には(Linuxでは)getrandom()関数を使ってランダムデータを生成しているようです2。getrandom()はランダムデータを生成するglibcの関数であり、同名のシステムコールを呼びます。
getrandom()関数のflagsにGRND_NONBLOCKを指定することで/dev/urandomと同じソースからランダムデータを生成することができるようです。/dev/urandomをopen()したりread()する必要がないので高速に動きます。古いLinuxではサポートされていないシステムコールなので注意が必要です。
簡単なCプログラムを書いて、それぞれ方式でののランダムデータ生成速度を測定してみました。各方式では、以下のようにランダムデータを生成しています。
/dev/urandomを直接読むgetrandom()関数を呼ぶRAND_bytes()関数を呼ぶ生成するデータサイズを変えながら、データ生成にかかった時間を計測しました（単位はナノ秒）:
$ ./bench
len urandom getrandom openssl
16 1932 61 1505
64 2067 160 427
256 2507 505 492
1024 4346 1807 592
生成データが小さい場合(len<=64)はgetrandomの方が圧倒的に性能が良く、生成するデータが大きくなっていくとOpenSSLの方が良くなる、という結果でした。PostgreSQLのUUIDv7実装では62 bitsのランダムデータを格納しているので、getrandom()を利用していたpgrx_uuidv7()が一番早かったのは納得です。
getrandom()が使えるのか？より速いUUID生成性能を得るために、開発コミュニティに提案したのがこちらです。
セキュリティ、性能、互換性などを中心に議論し、以下のような方針で進めようと思っています。
getrandom()を使う、みたいなことが可能になる。getrandom()が生成するランダムデータでもセキュリティ的な要件を満たせるケースはあるので、UUID生成のレイヤにてユーザが使用するランダムデータ生成方法を選択できるようにする議論のポイントとしては「セキュリティ＞速度」なので、OpenSSLを有効にしたビルドではこれまでの動作とは変えないようにしながら、ユースケースに応じてユーザが設定できるようにする、という点です。
特に最後の点は、getrandom()のvDSO実装によりさらなる性能的なメリットが得られることが議論を後押ししました。
詳しいことはわかりませんが、新し目のLinuxカーネルではvDSO(Virtual Dynamic Shared Object)という仕組みを利用して、ユーザ空間でgetrandomシステムコール相当の処理ができるようなったようです。コンテキストスイッチも不要かつ、カーネル空間→ユーザ空間へのコピーも不要なのでとても高速化されているとのことです。これは、Linux 6.11以降 + glibc 2.40以降で利用可能で、特に数百バイト程度のランダムデータ生成時にこの方式が利用されます。
実は先程の性能検証結果で使ったマシンにはRed Hat Enterprise Linux 10.0がインストールをされていて、vDSOのgetrandomを利用していました4。なので少量のランダムデータ生成では圧倒的に早かったということです。一応、getrandomシステムコールとの差を比べてみると、以下のような結果になりました。
$ ./bench
len urandom getrandom getrandom_sys openssl
16 1921 61 366 1536
64 2063 160 501 430
256 2506 506 953 490
1024 4351 1801 2780 593
最後にgetrandomを使ってPostgreSQLでUUIDv7を生成すると、どれくらい高速になるかを検証してみます。
この検証には、先程紹介したPostgreSQLコミュニティに提案中のパッチが必要となります。
| uuidv7() (/dev/urandomを利用) | uuidv7() (OpenSSLのRAND_bytes()を利用) | uuidv7() (getrandom)を利用 | pgrx_uuidv7() (参考) | |
|---|---|---|---|---|
| 実行時間(ms) | 2183.191 | 766.671 | 196.876 | 260.512 |
ついにPostgreSQLのuuidv7()が最も早くなりました！秒間約500万件のUUIDv7が生成できています。ちなみに、同環境では、シーケンスの値をnextval()関数で100万回取得するのに352.519msかかったので、シーケンスの払い出しよりも高速になったと言えます5。
UUID生成速度を上げるためにより速いランダムデータ生成方法を利用する、という話でした。
実際に比較してみると違いは一目瞭然です:
=# select uuidv4(), uuidv7() from generate_series(1, 5);
uuidv4 | uuidv7
--------------------------------------+--------------------------------------
216aae4c-6b02-4bea-bd84-7fea9617e0cc | 01991632-e3a0-7468-ac42-26afbc51df65
55372a64-0351-40a1-a32c-318e581f4561 | 01991632-e3a0-748a-bb4c-9882ddaf0721
e154c7a7-4a6b-4446-96be-6a1cb84b773e | 01991632-e3a0-749f-b429-d2ef56b9683e
59adba82-8a88-4f4f-b859-036430d09045 | 01991632-e3a0-74b5-9a86-8107f1851200
be096cb4-ee48-4bf8-ae30-3ca6d09af786 | 01991632-e3a0-74c9-a08a-1ec588e5a60d
(5 rows)
UUIDv7は、例えばデータベースの主キーとして使用した時に多くのメリットがあります。PostgreSQLでは主キーインデックスにはBtreeインデックスが使われます。そのため、大量にデータをロードした場合でも挿入されるUUIDのデータは常に昇順になるので、インデックス更新の局所性が高く、性能的に有利です。また、PostgreSQLではFull Page Writes（FPW）を抑える効果もあります。
SERIAL型（シーケンス）とUUID型（UUIDv4とUUIDv7）に主キーをつけた状態で500万件INSERTした結果は以下のとおりです(PostgreSQL 18 Betaで検証):
| SERIAL | UUIDv4 | UUIDv7 | |
|---|---|---|---|
| Druation | 8.452 s | 42.24 s | 16.922 s |
PostgreSQLはSQLのデータ型としてuuid型を持っていて、（PostgreSQL 17現在）UUIDを生成する方法は大きく2つあります。
一つは、組み込みのgen_random_uuid()SQL関数を利用する方法です。これはバージョン4のUUIDを生成します（バージョンの詳細については後述）。PostgreSQL独自の実装を利用しています。
もう一つは、uuid-ossp contribモジュールを使う方法です。UUID生成を外部ライブラリによって行うのですが、プラットフォームによって利用するライブラリはことなります。LinuxやmacOSではlibuuidを利用します。バージョン1 ~ 5まで生成可能です。
上記の通り、PostgreSQL 17現在、UUIDv7の生成をサポートしていないので、UUIDv7を利用したい場合は、公開されているextensionを利用する、もしくは自分で実装する必要があります。githubで探すと以下のextensionが見つかりました:
CREATE FUNCTIONを使えば利用可能pg_tle + PL/RustでUUIDv7を生成する関数を作るブロクもあります：
PL/Rustは利用できるcrateが限られているためRustのuuid crateは利用できません。自作ExtensionでUUIDv7を生成する関数を作りたい場合は、おそらくpgrx1を利用するのが一番簡単だと思います。UUIDv7の生成だけであれば以下のコードだけで可能です:
use pgrx::prelude::*;
use uuid::Uuid;
::pgrx::pg_module_magic!(name, version);
#[pg_extern]
fn pgrx_uuidv7() -> pgrx::Uuid {
let uuid = Uuid::now_v7();
pgrx::Uuid::from_bytes(uuid.into_bytes())
}
PostgreSQL 18ではuuidv7()SQL関数が導入されるため、すべてのPostgreSQLがユーザがUUIDv7を利用できるようになります(コミットログ)！
後方互換性のためgen_random_uuid()はこれまで通りUUIDv4を生成する関数として存在します。uuidv7()にあわせてuuidv4()も追加されましたがgen_random_uuid()のエイリアスです。
UUIDv7のフォーマットはRFCに以下のように記載されています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
すべてのUUIDにはデータ自体にそのバージョンが記載されています（verの部分）。
Version
|
v
01937a3a-3d34-74d0-a1b7-e1f1b53064d8
UUIDv7では、バージョンの前にミリ秒制度のタイムスタンプを入れ、バージョンの後にランダムデータ(正確には+variant)を入れる、というのがざっくりとしたフォーマットです。
timestamp random data(+var)
|-----------| |-------------------|
01937a3a-3d34-74d0-a1b7-e1f1b53064d8
ミリ秒精度のタイムスタンプでは精度が足りないというユースケースのために、RFCでは、rand_aの部分を（またはそれに加えてrand_bも)生成されたデータの単調増加性を維持すための追加データとして利用することを許可しています。そして、どのように使うことができるかの方法もいくつかRFCで紹介されています。
UUIDv7生成関数の実装毎に異なる使い方をしていますが、高頻度なUUID生成が行われる環境でもデータの単調増加性を維持すためにどのようにrand_aとrand_bを使うかはとても重要です。例えば、「ミリ秒精度のタイムスタンプ＋あとは全部ランダムデータ」といった一番単純フォーマットを利用したUUIDv7では、1秒間に1000個以上のUUIDが生成された場合、先頭のタイムスタンプはすべて同じ値になるので、生成されたUUIDv7のデータの単調増加性は保証されません。つまり、秒間1000個以上のUUIDのを生成する可能性あるシステムでは、そのようなUUIDv7生成関数を利用すると、UUIDv7の利点を活かしきることができません。ユースケースに応じて利用するUUIDv7生成関数を見極める必要があります2。
PostgreSQLのUUIDv7実装では、RFCで記載されているMethod 3(Replace Leftmost Random Bits with Increased Clock Precision)の方法を取り入れました。具体的には、rand_aの部分にミリ秒以下のタイムスタンプを入れ、全体で60(=48+12)ビットをタイムスタンプに使っています。これにより、秒間約400万個のUUID生成に耐えることが可能です。さらに、同一プロセス内ではUUID生成事にrand_aの部分が必ず増加するように調整しているので、それ以上の高頻度でのUUID生成でも単一プロセスから生成されるUUIDv7のデータは単調増加していることが保証されています。
また、引数にinterval値を入れることができ、UUIDデータに格納されるタイムスタンプを指定した期間だけずらすことも可能です。
ソースコードはここです。
RustでPostgreSQLのExtensionを作成するためのフレームワーク ↩
例えばpg_uuidv7の実装を見ると「ミリ秒精度のタイムスタンプ＋ランダムデータ」ということがわかります ↩
先日リリースされたPostgreSQL 17では、Vacuumの実行速度やメモリ使用量が大きく改善されています。内部的な情報なのでリリースノートでは言及されていませんが、その改善の立役者となったのはPostgreSQL 17で新しく実装されたradix treeです。以前はTIDの配列を使ってゴミタプルのTIDを管理していたのですが、PostgreSQL 17からはゴミタプルのTIDをradix treeに入れることにより、Vacuumがより早く、より省メモリで動くようになりました。radix treeの実装はこちらの論文をベースにしており、いくつか最適化を入れています。ソースコードに興味がある方はこちら。
インメモリでなにかのデータを保持したい場合、PostgreSQLのソースコードにはハッシュテーブルをはじめとしたいくつかのデータ構造が実装されています。
src/backend/utils/hash/dynahash.csrc/include/lib/simplehash.hsrc/include/lib/radixtree.hsrc/backend/lib/dshash.csrc/backend/lib/integerset.csrc/backend/lib/rbtree.csrc/backend/lib/ilist.c例えば、dynahash.cはPostgreSQL内部ではロック情報の管理など、様々なところで使われており、dshash.cはPostgreSQLの稼働統計情報を保持するコードで使われています。
それぞれ、データ構造としての特徴が異なることはもちろんですが、PostgreSQLでの実装という観点での特徴も異なります。例えば、dynahash.cはプロセスのローカルメモリ上にも共有メモリ上にもハッシュテーブルを作ることが可能ですが、ハッシュテーブルのサイズは固定です。一方で、dshash.cは共有メモリ上にのみハッシュテーブルを作ることができ、ハッシューテーブルは自動的に成長しますが、ハッシュテーブルの値（バリュー）は固定長ですし、ハッシューテーブルは成長はしますが小さくはなりません。これらの実装依存の特徴は将来変わる可能性があります。
radixtree.hの実装としての特徴は以下の通りです。
uint64で固定特に、可変長のバリューを持つことができ、共有メモリ上に作成できることは（今のところ）大きな特徴だと言えます。この特徴を使ってインメモリのキーバリューストアを作ってみました。
pg_memstoreは、PostgreSQLの拡張機能（Extension）で、共有メモリ上に作成したradix treeをベースとしたキーバリューストアです。可変長のバリューが持てる特徴を活かし、バリューにはjsonbデータが格納できます。
最初は簡単なSET、GETだけをサポートする予定だったのですが、作っていたら色々面白くなってきて、ファイルへのダンプ・リストア、WALサポートも実装してみました。
インストールはリポジトリ内のREADMEをご参照ください。
CREATE EXTENSION pg_memstoreを実行したら早速使ってみましょう。まずはシンプルな操作です。
=# SELECT memstore.set('key-1', '{"a": 1}'); -- return false if a new key
set
-----
f
(1 row)
=# SELECT memstore.get('key-1');
get
----------
{"a": 1}
(1 row)
=# SELECT memstore.set('key-1', '{"a": 999}'); -- update the value
set
-----
t
(1 row)
=# SELECT memstore.get('key-1');
get
------------
{"a": 999}
(1 row)
=# SELECT memstore.set('key-2', '{"b": [1, 2, 3]}');
set
-----
f
(1 row)
=# SELECT * from memstore.list();
key | value
----------------+------------------
\x6b65792d317e | {"a": 999}
\x6b65792d327e | {"b": [1, 2, 3]}
(2 rows)
=# SELECT memstore.delete('key-2');
delete
--------
t
(1 row)
=# SELECT * from memstore.list();
key | value
----------------+------------------
\x6b65792d317e | {"a": 999}
(1 row)
共有メモリ上に作られているので、他のセッションからもアクセス可能です：
=# SELECT memstore.get('key-1');
get
------------
{"a": 999}
(1 row)
=# \c -
=# SELECT memstore.get('key-1');
get
------------
{"a": 999}
(1 row)
メモリ使用量を確認することもできます：
=# SELECT memstore.memory_usage();
memory_usage
--------------
262144
(1 row)
memstore.save()でディスク上にダンプし、memstore.load()でロードすることも可能です。
また、pg_memstore.wal_logging = trueに設定すると、memstore.set()とmemstore.delete()の情報がWALに書かれるので、レプリケーションのスタンバイサーバでも同じデータを持つことができます。
pg_memstoreを実装したことで2つPostgreSQLのバグを見つけることができました。1つは修正済みですが、もう一つは議論中です。READMEにも書いてありますが、PostgreSQL本体でこのバグが直るまで、memstore.list()とmemstore.save()は使えません。
キーバリューの情報をシャットダウン時にディスクに保存するために「CHECKPOINT時やサーバシャットダウン時に、DSA上に作成したデータをファイルに書く」みたいな挙動をやりたかったのですが、現在のPostgreSQLではできなさそうです。最初に検討したのは、「シャットダウン時にradix treeに入っているデータを一つずつファイルに書く」ですが、これはpostmasterがやる必要があります。しかし、現在postmasterがDSA上のデータを触ることはできないようです（正確にはその内部で使っているDSMにアクセスできない）。次に、checkpointerがCHECKPOINT時にそれをやる方法を考えたのですが、現在CHECKPOINT時にhook等でコードを入れ込むことはできません、この辺りは将来改善できるかもなと思いました。
]]>glibcとの比較はこちら。
このmusl libcを使うPostgreSQLをビルドする方法のメモ。
ソースコードはここから取得可能。musl.ccというビルド済みのバイナリをダウンロード出来る所もあるらしいが、今回はソースコードをビルドした。
$ wget https://musl.libc.org/releases/musl-1.2.5.tar.gz
$ tar zxf musl-1.2.5.tar.gz
$ cd musl-1.2.5
$ ./configure --prefix=/home/masahiko/musl --syslibdir=/home/masahiko/musl-lib/
$ make
$ make install
--prefixと--syslibdirオプションで、musl libcがインストールされるディレクトリとダイナミックリンカがインストールされるディレクトリを指定する。ビルドは20秒程度で終わった。
インストール先のbinディレクトリにmusl-gccというプログラムがあればOK。
$ ls /home/masahiko/musl/bin
musl-gcc
これはgccのラッパー(中身はシェルスクリプト)で、これを使ってプログラムをコンパイルするとmusl libcにリンクするようになるらしい。
開発版のHEADを使ってビルドする。
下準備として、先程インストールしたmusl-gccをPATHに含めておく。
$ export PATH=/home/masahiko/musl/bin:$PATH
また、/usr/include/linux、/usr/include/asm、/usr/include/asm-genericをディレクトリごと、musl libcをインストールしたところにコピーする。
$ cd /home/masahiko/musl/include
$ cp -rs /usr/include/linux linux/
$ cp -rs /usr/include/asm asm/
$ cp -rs /usr/include/asm-generic asm-generic/
これをする理由は後ほど。
PostgreSQLのソースコードをダウンロードして、ビルドする。
$ git clone git://git.postgresql.org/git/postgresql.git
$ cd postgresql
$ ./configure --prefix=/home/masahiko/pgsql CC=musl-cc --without-readline --without-icu --witout-zlib
$ make
$ make install
CC=musl-ccについてCCには使用するコンパイラを指定できる。
--without-XXXの指定についてPostgreSQLがデフォルトでreadline, zlib, icuを有効にしてビルドする（configureの場合）。例えば、readlineのヘッダファイルは/usr/include/readlineにあるけど、/usr/includeにはglibcのヘッダファイルもある。なので/usr/includeを探しに行くように設定するとmusl-gccを使ったビルドができなかった。なので、これらのライブラリは無効にした状態でビルドする。今回はお試しなのでこれでOK。
下準備として/usr/include/linux等をディレクトリごとコピーしたのはこれに対応するため。これは推奨された方法ではないらしいけど今回はこれでOKとした。おそらく、readline等も同じようにすればビルド出来るのだと思う。
readline等はなくてもPostgreSQLのビルドは出来るけど、/usr/include/linux等はPostgreSQLのビルドに必須だったので今回はこの方法を使った。これがないと、自分の環境は以下のエラーが出た。
musl-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-
local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -I../../../src/interfaces/libpq -I../../../src/include -D_GNU_SOURCE
-c -o pg_combinebackup.o pg_combinebackup.c
pg_combinebackup.c:24:10: fatal error: linux/fs.h: No such file or directory
24 | #include <linux/fs.h>
| ^~~~~~~~~~~~
自分の環境では、以下のようなWARNINGが出た。ビルド自体はできたので問題なし。
pg_get_line.c: In function _pg_get_line_append_:
pg_get_line.c:129:27: warning: _({anonymous})_ may be used uninitialized [-Wmaybe-uninitialized]
129 | if (prompt_ctx && sigsetjmp(*((sigjmp_buf *) prompt_ctx->jmpbuf), 1) != 0)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PostgreSQLがビルドできたら、ちゃんとmusl libcにリンクするようになっているかを確認する。
$ ldd bin/postgres
linux-vdso.so.1 (0x00007ffd0bdf6000)
libc.so => /home/masahiko/musl/lib/libc.so (0x00007f21be639000)
musl libcはglibcに完全互換しているわけではなく、若干挙動が違ったりするとのことだけど、make check-worldも通って一安心。
musl libcの方がライブラリとしてはglibcより小さいけど、性能はglibcの方が早いとのことなので、性能面も比較してみたい。
]]>趣味実装かつ、作成途中なのでプロダクション環境では利用しないでください！
CREATE EXTENSIONでpgroadをデータベースに登録します(あらかじめshared_preload_libraiesへpgroadの追加する必要があります)。
=# CREATE EXTENSION pgroad;
CREATE EXTENSION
サンプルデータとしてpgbenchでテーブルを作成します。
$ pgbench -i -s 100
dropping old tables...
creating tables...
generating data (client-side)...
vacuuming...
creating primary keys...
done in 10.43 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 7.41 s, vacuum 0.16 s, primary keys 2.86 s).
$ psql
=# \dt+ pgbench_accounts
List of relations
Schema | Name | Type | Owner | Persistence | Access method | Size | Description
--------+------------------+-------+----------+-------------+---------------+---------+-------------
public | pgbench_accounts | table | masahiko | permanent | heap | 1281 MB |
(1 row)
pgbench_accountsテーブルは現在heapテーブルですが、これをroadテーブルに変換します。
=# ALTER TABLE pgbench_accounts SET ACCESS METHOD road;
ALTER TABLE
=# \dt+ pgbench_accounts
List of relations
Schema | Name | Type | Owner | Persistence | Access method | Size | Description
--------+------------------+-------+----------+-------------+---------------+--------+-------------
public | pgbench_accounts | table | masahiko | permanent | road | 118 MB |
(1 row)
テーブルサイズが1281MB → 118MBに小さくなったことがわかります。一度roadテーブルへ変換すると、新しいデータを変更、追加、削除することはできません。
=# DELETE FROM pgbench_accounts ;
ERROR: road_tuple_delete is not supported
=# INSERT INTO pgbench_accounts (aid) VALUES (1);
ERROR: cannot insert tuple directly into a ROAD table
HINT: Use ALTER TABLE ... SET ACCESS METHOD or CREATE TABLE ... AS to insert tuples
作りは非常に単純です。既存のテーブルをスキャンしながら、16KBページ（メモリ上）にタプルを格納していき、ページが満杯になったら圧縮してroadテーブルに書き込みます。
+-------------------+ +------------+ compression +---------+
| | --> | chunk | -------------> |xxxxxxxxx| \
| | | (16kB) | +---------+ \
| | +------------+ \ +--------------------+
| original table | \ | |
| (heap, 8kB pages) | +------------+ compression +---------+ `-> | new table |
| | --> | chunk | -------------> |xxxxxxxxx| --------> | (road, 8kB pages) |
| | | (16kB) | +---------+ .-> | |
| | +------------+ / | |
| | / +--------------------+
| | +------------+ compression +---------+ /
| | --> | chunk | -------------> |xxxxxxxxx| /
| | | (16kB) | +---------+
| | +------------+
+-------------------+
今のところroadテーブル内のタプルはHeap Tupleを利用しています。ですが、Heap Tupleのヘッダにはroadが必要としていないデータがいくつかあるので(xminやxmaxなど)、独自のタプルフォーマットをサポートしてみたいなと思っています。
圧縮方法はデフォルトはpglz。PostgreSQL本体が対応していればlz4も指定可能です。
「既存のテーブルをroadへ変換する」というユースケースに絞って作成したので、roadテーブルを作成する方法は以下の2つ限られています：
ALTER TABLE ... SET ACCESS METHOD roadCREATE TABLE ... USING road AS ...また、トランザクション内では作成できません。
特定のDDLコマンドが実行されたかどうかを知るにはProcessUtility_hookが利用できます。PostgreSQLにはhookポイントと呼ばれる箇所がいくつかあり、拡張機能内で自身の関数を差し込むことが可能です。ProcessUtility_hookはPostgreSQLが提供するHookポイントの一つで、DDLが実行されるときに呼ばれます。
pgroadではこのProcessUtility_hookを使って、実行されたSQLがCREATE TABLE ASもしくはALTER TABLE ... SET ACCESS METHOD roadかどうかを判別しています。
static void
road_ProcessUtility(PlannedStmt *pstmt, const char *queryString,
bool readOnlyTree,
ProcessUtilityContext context, ParamListInfo params,
QueryEnvironment *queryEnv,
DestReceiver *dest, QueryCompletion *qc)
{
NodeTag tag = nodeTag(pstmt->utilityStmt);
if (tag == T_CreateTableAsStmt)
{
RoadInsertState.called_in_ctas = true;
Assert(!RoadInsertState.called_in_atsam);
}
else if (tag == T_AlterTableStmt)
{
AlterTableStmt *atstmt = (AlterTableStmt *) pstmt->utilityStmt;
ListCell *cell;
foreach(cell, atstmt->cmds)
{
AlterTableCmd *cmd = (AlterTableCmd *) lfirst(cell);
if (cmd->subtype == AT_SetAccessMethod)
{
Relation rel = relation_openrv(atstmt->relation, ShareLock);
/*
* Are we about to change the access method of the relation to
* ROAD table AM?
*/
if (strcmp(cmd->name, "road") == 0)
{
/* Remember the original table's OID */
RoadInsertState.atsam_relid = RelationGetRelid(rel);
RoadInsertState.called_in_atsam = true;
}
RelationClose(rel);
break;
}
}
Assert(!RoadInsertState.called_in_ctas);
}
prev_ProcessUtility(pstmt, queryString, false, context,
params, queryEnv, dest, qc);
}
この関数で「どのようなDDLが実行されたのか」を覚えておき、後に呼ばれるINSERTのためのコールバックで実際のエラーを出しています。
static void
road_tuple_insert(Relation relation, TupleTableSlot *slot,
CommandId cid, int options, BulkInsertState bistate)
{
RoadInsertStateData *state;
ItemPointerData tid;
RowNumber rownum;
bool shouldFree;
HeapTuple tuple = ExecFetchSlotHeapTuple(slot, true, &shouldFree);
state = road_get_insert_state(relation);
if (!(state->called_in_atsam || state->called_in_ctas))
ereport(ERROR,
(errmsg("cannot insert tuple directly into a ROAD table"),
errhint("Use %s or %s to insert tuples",
"ALTER TABLE ... SET ACCESS METHOD",
"CREATE TABLE ... AS")));
PostgreSQLの自作テーブルAMの実体は「コールバックのまとまり」であり、自作テーブルAMがサポートしたいテーブルに関する機能（例えば、シーケンシャルスキャン、インデックススキャン、インデックス構築など）に応じて、必要なコールバックを実装する必要があります。そして、テーブルAMはPostgreSQLの中でうまく抽象化されており、他のコンポーネントとは独立して実装することが可能です。PostgreSQL本体がトランザクションやバッファマネージャなどの機能を提供しているので、テーブルAM内でそれを使うか使わないかは、実装者が選択することができます。例えば、PostgreSQL本体のバッファマネージャの機能を利用することで、テーブルAM開発者は、共有バッファより下の層を意識することなく実装できます。
ただし、テーブルAMを実装するとなると、コールバックの実装以外にも考えることはたくさんあります。
これらをじっくり考えて理想のテーブルAMを作るもの良しですが、とりあえず作ってみたいという場合は、ユースケースをできるだけ絞ることをおすすめします。ユースケースを絞ることで制約が増えますが、考慮しなくてはいけないことが減り、実装量も減り、実装もシンプルになり易いです。まずは「単純で実用的ではないかもしれないけど動く物」を作ることで、モチベーションも上がります。テーブルAMに限らずですが、手を動かして実装してみるその過程自体が一番大切なので、実際中身は何でも良いと思います。
pgroadは以下のような制約があります。思い切ってこれらの制約をつけることで実装が格段に楽になりました。
pgroadはアーカイブ用のTable AMでしたが、他にも実装してみると面白そうなアイディアがいくつかあります。
などなど。
ぜひ自作Table AMの作成を通して、PostgreSQLの拡張機能開発に挑戦してみてください！
]]>PostgreSQLのトランザクションID（以下XID）は内部的には「単調増加する32bitの非負整数値」なので、2^32-1に達した後は0に戻ります。PostgreSQLでは、データベースに変更を加えるトランザクションに対して1つXIDが割り当てられます。XIDの大小関係を利用してテーブル内の行の可視性判断[^visibility]をしているので、XIDが上限に達して周回してしまうとそのロジックが壊れてしまいます。
そこでPostgreSQLでは周回が起こる前（具体的にはXIDを2^31(≒約20億)個消費する前）に、aggressive vacuumと呼ばれる安全装置のようなものが自動的に走り、XIDを更に消費できるようにします（詳細は公式ドキュメントをご参照ください）。ここ数年、この安全装置周りの改善に取り組んでいたので、安全装置自体をテストや、安全装置の動作完了が間に合わなかった場合のテストなどすることが多くありました。ただ、XIDと安全装置の性質上、XIDを大量に消費しないと適切なテストができず、これには時間がかかります。
例えばナイーブにやろうとすると、約20億のトランザクションを実行する必要があります。また、新しいXIDを発行する際には各XIDにステータスを持つようなデータ、例えばCLOGやCommit Timestampなどの領域も合わせて拡張されます。それらの動作をテストするときにも、実際にXIDを消費することが重要になる時があります。
そこで、早くXID消費するための色々な方法を紹介します。
次のようなユーザ定義関数を使って10億XIDを消費します。内部的にはサブトランザクションを10億個生成することで、XIDを消費しています。
CREATE PROCEDURE consume_xids(cnt int)
AS $$
DECLARE i int;
BEGIN
FOR i in 1..cnt LOOP
EXECUTE 'SELECT txid_current()';
COMMIT;
END LOOP;
END;
$$
LANGUAGE plpgsql;
=# select pg_current_xact_id();
=# call consume_xid(100_000_000);
Time: 797958.576 ms (13:17.959)
=# select pg_current_xact_id();
13分と結構時間がかかりました。XIDの生成は排他ロックを取るので並列化しても大きな改善は見込めません。
pg_resetwalというPostgreSQL内部情報を初期化するツールを使い、次のXIDを強制的に設定します。内部情報を書き換えているだけなので、pg_resetwalは一瞬で完了するはずです。
$ psql -c "SELECT pg_current_xact_id()"
$ pg_ctl stop
$ pg_resetwal -x 2000027648
$ pg_ctl start
$ psql -c "SELECT pg_current_xact_id()"
XIDを2000027648に進めるのは、次のXIDをCLOGのページ（8kB）境界にするためです。そうしないと、起動するときにトランザクションのステータス（CommitとかAbortとか）にアクセスできない旨のエラーがでてしまいます。これは、サーバ起動時に現在のXIDのステータスがCLOGページの境界にない場合、そのページ内のまだ使っていないXIDのStatusを0に初期化するがあるためです（詳細はTrimCLOG()参照）。さらに、XIDをかなり大きくスキップしているのでそれに対応するCLOGページはまだできておらず、ファイルアクセスエラーになります。
これは、pg_resetwalを使うすべてのケースに当てはまるので注意が必要です（ただし通常のユースケースでは、こんなに大きくXIDをスキップさせないので問題にならない）。
CLOGのページ境界に次のXIDを持っていくために、8kBのCLOGページに32768個のXIDについての情報を格納できるので、32768 * (2000000000/32768 + 1) = 2000027648と計算しています。
pg_resetwalでXIDを大幅にスキップした後にあとはtxid_current()等の関数でXIDを消費します。
簡単に、かつ高速にXIDを進めることができるますが、”リアル”なユースケースではないというのが欠点です。XIDを消費していく中で実行されていく処理（例えばCLOGの拡張など）はスキップしてます。再起動も必要だし、新しいXIDは狙い撃ちする必要があります。ページサイズにも依存します。
今度は自分で作った関数で内部的にXIDを設定してみます。
PG_FUNCTION_INFO_V1(set_next_xid);
Datum
set_next_xid(PG_FUNCTION_ARGS)
{
TransactionId next_xid = PG_GETARG_TRANSACTIONID(0);
TransactionId xid;
uint32 epoch;
if (!TransactionIdIsNormal(next_xid))
elog(ERROR, "cannot set invalid transaction id");
LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
if (TransactionIdPrecedes(next_xid,
XidFromFullTransactionId(TransamVariables->nextXid)))
{
LWLockRelease(XidGenLock);
elog(ERROR, "cannot set transaction id older than the current transaction id");
}
/*
* If the new XID is past xidVacLimit, start trying to force autovacuum
* cycles.
*/
if (TransactionIdFollowsOrEquals(next_xid, TransamVariables->xidVacLimit))
{
/* For safety, we release XidGenLock while sending signal */
LWLockRelease(XidGenLock);
SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_LAUNCHER);
LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
}
ExtendCLOG(next_xid);
ExtendCommitTs(next_xid);
ExtendSUBTRANS(next_xid);
/* Construct the new XID */
epoch = EpochFromFullTransactionId(TransamVariables->nextXid);
xid = XidFromFullTransactionId(TransamVariables->nextXid);
if (unlikely(xid > next_xid))
++epoch;
TransamVariables->nextXid =
FullTransactionIdFromEpochAndXid(epoch, next_xid);
LWLockRelease(XidGenLock);
PG_RETURN_VOID();
}
C言語でユーザ定義関数を書く必要があるますが、1つ前の方法とは異なり、サーバの再起動は不要になりました。さらに、新しいXID付近のCLOGやCommitTsも拡張するし、新しく設定するXIDが十分に古い場合は、aggressive vacuumをしてもらうためにautovacuum launcherを起こすようにもなっています。この関数も一瞬で完了するはずです。
=# select txid_current();
txid_current
--------------
737
(1 row)
Time: 0.850 ms
=# select set_next_xid('999981056'::xid);
set_next_xid
-----------lang: jp
---
(1 row)
Time: 0.483 ms
=# select txid_current();
txid_current
--------------
999981056
(1 row)
Time: 0.926 ms
しかし、ExtendCLOG()等の関数は、受け取ったXIDがページ内の境界となるようなXIDである場合にのみ対応するページを作成するため、先程の方法と同様、設定するXIDは狙い撃ちする必要があります。また、この関数はXIDを進めているというよりも”ジャンプしている”という感じです。新しく設定したXID周辺のCLOGを拡張することはできますが、そこまでのXIDについては何もしていません。
最後に紹介するのは、最近masterブランチ（開発用ブランチ）にコミットしたxid_wraparoundというテスト用の拡張で採用している方法です。
xid_wraparoundは、リグレッションテスト用に作られましたが、そこで定義されているSQL関数は、xid_wraparoundの拡張をインストールすればどの環境でも使えます。
=# CREATE EXTENSION xid_wraparound;
CREATE EXTENSION
=# \dx xid_wraparound
List of installed extensions
Name | Version | Schema | Description
----------------+---------+--------+--------------------------
xid_wraparound | 1.0 | public | Tests for XID wraparound
(1 row)
=# \dx+ xid_wraparound
Objects in extension "xid_wraparound"
Object description
-----------------------------------
function consume_xids(bigint)
function consume_xids_until(xid8)
(2 rows)
`これまでの方法と異なるのは、XIDを”スキップしながら進めている”という所です。CLOGやCommitTsを拡張する必要があるXID（コード内では”interesting xids”と呼ばれている）周辺では通常通りのやり方でXIDを消費しますが、それ以外のところは1つ前に紹介した方法のように、内部的にXIDを設定してスキップしています。
=# select txid_current();
txid_current
--------------
737
(1 row)
=# select consume_xids('1000000000');
NOTICE: consumed 10000071 / 1000000000 XIDs, latest 0:10000809
NOTICE: consumed 20000880 / 1000000000 XIDs, latest 0:20001618
NOTICE: consumed 30001689 / 1000000000 XIDs, latest 0:30002427
NOTICE: consumed 40002498 / 1000000000 XIDs, latest 0:40003236
NOTICE: consumed 50003230 / 1000000000 XIDs, latest 0:50003968
NOTICE: consumed 60003297 / 1000000000 XIDs, latest 0:60004035
NOTICE: consumed 70003998 / 1000000000 XIDs, latest 0:70004736
NOTICE: consumed 80004096 / 1000000000 XIDs, latest 0:80004834
NOTICE: consumed 90004766 / 1000000000 XIDs, latest 0:90005504
NOTICE: consumed 100004895 / 1000000000 XIDs, latest 0:100005633
NOTICE: consumed 110005534 / 1000000000 XIDs, latest 0:110006272
NOTICE: consumed 120005694 / 1000000000 XIDs, latest 0:120006432
NOTICE: consumed 130006302 / 1000000000 XIDs, latest 0:130007040
NOTICE: consumed 140006493 / 1000000000 XIDs, latest 0:140007231
NOTICE: consumed 150007070 / 1000000000 XIDs, latest 0:150007808
NOTICE: consumed 160007292 / 1000000000 XIDs, latest 0:160008030
NOTICE: consumed 170007838 / 1000000000 XIDs, latest 0:170008576
NOTICE: consumed 180008091 / 1000000000 XIDs, latest 0:180008829
NOTICE: consumed 190008606 / 1000000000 XIDs, latest 0:190009344
NOTICE: consumed 200008890 / 1000000000 XIDs, latest 0:200009628
:
:
NOTICE: consumed 960038174 / 1000000000 XIDs, latest 0:960038912
NOTICE: consumed 970038423 / 1000000000 XIDs, latest 0:970039161
NOTICE: consumed 980038942 / 1000000000 XIDs, latest 0:980039680
NOTICE: consumed 990039222 / 1000000000 XIDs, latest 0:990039960
consume_xids
--------------
1000000738
(1 row)
Time: 2893.244 ms (00:02.893)
=# select txid_current();
txid_current
--------------
1000000739
(1 row)
実行速度もそれなりに早いです。そこそこはやくXIDを消費しつつ、XID消費に伴う処理も従来通りの方法で行われるので、より”リアル”なXID消費をシミュレーションできます。
autovacuum launcherを起こす処理は入れていないので、autovacuum launcherがaggressive vacuumのために起きるタイミングは、設定したXIDやautovacuum_naptimeに依存します。このあたりは将来変わる可能性があります。
ぜひこの方法を使って快適なXID消費ライフを！
]]>