Experimental approach towards Replication in Postgres
summary
Experimental prototype replaces Postgres TCP unicast streaming with PIM-BIDIR multicast sockets to cut primary CPU, kernel buffer and NIC bandwidth by sending one stream instead of N. Paper claim: a 15‑replica case goes from ~15x overhead to ~1x 15x bandwidth reduction; recovery uses RFC3208 designated local repairer caches, sequence numbers and NACKs, with QUIC-over-multicast considered for reliability. Modules (multicast sender/receiver, DLR, recovery hooks) are implemented experimentally, benefits look large but it remains a prototype requiring multicast‑enabled routers, extensive testing and careful integrity/recovery work before production.
AI-written summary · about
chapters (10)
- 0:00Introduction to experiment
- 1:50Limitations of TCP unicast
- 5:24Unicast vs multicast comparison
- 8:58Protocol Independent Multicast
- 13:11Reliability in multicast
- 16:24Failover and recovery
- 17:52Advantages of multicast
- 18:35Challenges and testing
- 19:18Conclusion and future work
- 20:02Q&A session
related talks
49mPostgreSQL Replication - The Most Exciting Technology on Earth
53mMulti master replication for painless fault tolerance
22mSecuring Postgres with streaming replication
39mLogical Replication handling of large transactions
55mHigh Availability with PostgreSQL and Pacemaker
22mPostgreSQL Disaster Recovery Fundamentals
42mPostgreSQL Distributed: Architectures & Best practices
50mParallel Recovery in PostgreSQL