The Hitchhiker’s Guide to PostgreSQL Hacking: Don’t Panic, Just Start Small
summary
A practical roadmap: start by reviewing patches, run make check and reproduce tests, then use perf and benchmarks to connect design to measurement. Implements a server-side WAIT FOR LSN command with standby_replay, standby_write, standby_flush, primary_flush modes to avoid client polling. Benchmarks show polling costs ~10× cycles, ~5× instructions, ~7× cache misses and ~3× task clock versus WAIT FOR LSN. Review workflow follows four layers: build/test, behavior/errors, performance/concurrency, and architecture/documentation.
AI-written summary · about
chapters (13)
- 0:00Music & introduction
- 0:55Why Postgres hacking feels intimidating
- 2:40Start small with patch reviews
- 4:14Navigating mailing lists & CommitFest
- 5:34The four layers of patch review
- 8:47Reviewing the wait for LSN patch
- 9:40read-after-write consistency explained
- 11:43Why polling replicas is expensive
- 15:19Wait for LSN removes polling overhead
- 17:11Benchmarking polling vs wait for LSN
- 18:45How community feedback shapes features
- 22:29Designing flexible wait for LSN modes
- 23:07Lessons learned from Postgres hacking journey
related talks
47mBeginner's guide to PostgreSQL Hacking
50mHacking on Postgres: An Overview
01h 00mThe 10 Deadly PostgreSQL Sins
50mPostgreSQL hacker tips
36mPostgreSQL worst practices
57mPostgreSQL When It's Not Your Job
11mThe Seven Principles for Making a PostgreSQL DB Work Fast
48mUnderstanding and Reducing Application Contention