hmarui66

動画の最後の方のQ&A: Multigresプロジェクトを進めるにあたり、頭痛の種だったPostgreSQLの側面は？ →WALの作り。理由はレプリカをほとんど制御できないから。 とのこと youtu.be/9_kbqi9XYE8?t=…

とても含蓄深く、めちゃ面白かった。 バージョンアップ、DB移行以前にそもそもソフトウェアエンジニアはみんな読んだほうがいい。 labs.gree.jp/blog/2026/03/2…

逆に時刻保証が得られない状態で一貫性が欲しければ、リースによる最適化を諦める

(おそらく)最新のRaftのリースアルゴリズムであるLeaseGuardの論文でも時刻のズレ幅の保証は得られる前提(2.2.Clocks with bounded uncertaintyあたり)を置いているので、時刻幅の保証が無ければ少なくとも一貫性が壊れるのは諦めるしかないんですかね… arxiv.org/html/2512.1565…

Multigresの合意についての記事シリーズを少しずつ読み進めているのだけどこれは、柔軟に構成可能な合意(というか耐久性？)、という理解で良いのかな。

耐久性をプラグイン可能に。 確かにRaftなど有り物使うと、細やかな耐久性要件の調整難しいか。 過剰プロビジョニングとかに繋がる。 #pluggable-durability" target="_blank" rel="nofollow noopener">multigres.com/blog/generaliz…

#why-are-we-even-doing-this" target="_blank" rel="nofollow noopener">multigres.com/blog/generaliz… なぜ合意を整理し直しているか？ - システムをより深く理解したい - 既存実装は多数決に基づいているので柔軟性低い(FlexPaxosの実装ない) - (実装がモノリシックで)関心事に分離できない これらを整理して、Postgres WALレプリケーションで合意を機能させたい

Vitessのco-creatorで今はSupabaseでMultigres作ってる人のCMUセミナー動画、面白い(難しい) コンピュートとストレージは分離しない方が良い(ラウンドトリップ排除)、合意をDBのユースケースから再定義(ここ難しい…11部構成のブログがあるらしい) youtu.be/9_kbqi9XYE8?si…

今日のDB朝輪で、strict serializabilityより強いopacityという分離のレベルを知った。 アボートされるトランザクションすらも不整合を見ないというもの。 RDB文脈では出てこないけど、ソフトウェアトランザクショナルメモリでは一般的にこれと。 dl.acm.org/doi/10.1145/37…

Here is an insane piece of lore inside SQLite's source code I am researching VACUUM and I was studying their code. In VACUUM, SQLite creates a temp file prefixed with `etilqs_` Here is why:

Pointer Swizzling適用によるポインタ直参照→仮想メモリ活用する手法vmcache→hintベースで参照スキップするLIPAH→CPUスーパースカラー活用のpredicache→配列ベースの変換の課題克服CALICO

SIGMOD'26論文のpredicacheを比較対象に挙げてるAndy Pavlo&Stonebreaker関連の論文が出てるのだけど、バッファマネージャ地味に？ホットな領域。 arxiv.org/abs/2604.00423

出遅れたけど、試した結果をリリース。 Amazon S3 Files が GA — S3 バケットをファイルシステムとしてマウント、EFS と比較してみた dev.classmethod.jp/articles/amazo… #DevelopersIO

@roadsidestone1 rtもそうですが、これだけの規模のプロジェクトで、この手の技術課題に取り組んで少しずつでも進捗させているのは、純粋に凄いなと感じますね。

@hmarui66 カーネル側の警告を軽んじた実装で積み上がった負の遺産を地道に潰してる空気が伝わりますね。 しかし、rtのメインライン統合も20年がかり。 ここはやり切っていただくしかないです。

> PostgreSQLのスピンロックを頑張って減らしている人のコメント面白い (コミッターのfujiiさんの投稿で知った) 見返すとただの人みたいに書いちゃっているけど、この方もコミッター

返信に、件のワークロード自体あまり現実味無いという話も書いてある。やはりそれはそう。 あと、buffer 置換対象の選択は10年近くロックフリーで、unused buffer のリストのみがスピンロックで守られてた & 最近スピンロック削除、とのこと。

PostgreSQLのスピンロックを頑張って減らしている人のコメント面白い (コミッターのfujiiさんの投稿で知った) futexベースにするとロック解放時にメモリバリアが必要でバリアの増加はリグレッションを引き起こしたり、既存のスピンロック実装自体も移行を難しくしていると news.ycombinator.com/item?id=476492…

スピンロックの利用自体が間違ってるかのようなコメントが散見されたので、それはちょっとどうかとだけ言っておきたい。

あとスピンロックのみに頼るのがまずいのはそうだけど、最初スピンしてダメなら切り替えるみたいな手法はOS側含めて良くある認識なので、一律NGという話でもないはずだなと。 分かってる人はその前提で書いてると思うけど。

↑のメーリスによるとPostgreSQLでもスピンロックの排除は進められていて、今回問題視されているパスでのスピンロックはv19では無くなっていると。 なんか、影響としてもデフォルトでプリエンプトnone指定のOSでの問題とも言えるみたいだし、問題視すべきものなのか分からないな…ベンチ難しい問題。

これと、これについて言及している投稿を後で読もう joho-todai.com/linux-7-postgr…