Hazards of logical decoding in PostgreSQL
summary
Explains why logical decoding can blow up disk and CPU: every slot spawns a WalSender that decodes the shared pg_wal stream single‑threaded, uses work_mem and a reorder buffer that spills to disk, and stalled persistent replication slots keep restart_lsn and catalog_xmin from advancing so pg_wal grows. Shows a pg_repack example that writes massive WAL for a temp table that is then filtered away, cites pg_stat_replication_slots and confirmed_flush_lsn for monitoring, warns about Patroni slot re‑creation, and notes a pgJDBC bug that stalled shutdown and hit Debezium.
AI-written summary · about
chapters (6)
- 0:00Intro
- 2:01Logical decoding
- 2:59Decoding process
- 9:44Logical decoding slot
- 17:46Replication protocol
- 21:00Conclusion
related talks
54mUnderstanding Logical Decoding and Replication
29mLogical replication theory and concepts
38mPostgres 16 highlight: Logical decoding on standby
31mPast, Present, and Future: Logical Decoding and Replication in PostgreSQL
48mPostgreSQL Replication: 20 Pitfalls and Solutions
26mThe Wonderful World of WAL
38mA journey into postgresql logical replication
28mWhere Does My INSERT Go? A Logical Replication Story
