postgres=# select * from sessions where video_id = 'mVYl2RHlpoE';

Vibe Hacking Postgres

· 51:42 · Storage internals

Test B-tree page merge against concurrent scans and expose correctness failures.

session summary

The group assessed the B-tree page-merge prototype after community feedback. They agreed benchmarks should emphasize extra buffer I/O, cache pollution, WAL, and sparse-page workloads rather than lookup latency alone. A new injection-point test then demonstrated the critical flaw: a concurrent forward scan returned duplicates while a backward scan missed tuples after pages were merged. Several recovery schemes were examined, but repeated vacuums and concurrent inserts defeated the simple designs. The session ended with correctness and concurrency still unresolved.

timecodes

  1. Community feedback and the benchmark requirement
  2. Why sparse pages hurt buffers, WAL, and vacuum
  3. Scoping useful page-merge benchmarks
  4. Injection-point test exposes incorrect scans
  5. Visualizing the old-tree and new-tree race
  6. Concurrent inserts and possible query aborts
  7. When scans can recover from merged pages
  8. Why limited merges and repeated vacuums still fail