Sparta’s Dual Kingship and PostgreSQL Active-Active
summary
PostgreSQL 16 makes origin tracking practical so bidirectional logical replication can run, but identical primary keys and concurrent commits create duplicate key failures unless resolved. Practical fixes shown: add commit timestamps and apply last update wins to discard older rows while storing discarded rows for audit, use a small consensus service (a consensus lock / Gia) to serialize DDL and allocate sequence ranges, mix logical with physical replicas for DR, and expect fast switchovers (~100–200 ms). Extensions BDR, PGH and PG-Active implement many of these ideas.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 2:55How the people remember Sparta
- 3:50Why do you need ActiveActive
- 6:25Getting it right
- 12:00ActiveActive
- 13:40Conflicts
- 18:18Conflict Resolution
- 20:37Data Definition Language
- 23:06Sparta and Athens
- 27:37Consensus
- 30:40Disaster Recovery
- 38:02Conclusion
- 41:24Test your assumptions
- 42:10Questions
related talks
44mThe journey towards active-active replication in PostgreSQL
53mThe journey towards active replication in PostgreSQL
50mEvolution Of PostgreSQL Replication and High Availability (upto ~ 99.999%)
55mHigh Availability with PostgreSQL and Pacemaker
31mPast, Present, and Future: Logical Decoding and Replication in PostgreSQL
50mMoving from MSSQL to pgSQL – High Availability and Disaster Recovery
46mPostgreSQL 16 and beyond
42mPostgreSQL Replication Conflicts: Avoiding Pitfalls