Navigating Challenging Customer Escalations in Postgres
summary
Describes concrete failure modes and mitigations: a hard 64 subtransaction per-backend cache limit causes subtransaction cache overflow (customers hit 300–900 nested savepoints), debugged with GDB and resolved by a custom pg17 build that adds a configurable SLRU size and partial‑associative caching; database corruption detection uses pg_dump, pg_verifycheck and pg_catalog_check plus pg_surgery for repairs; autovacuum and wraparound risks are tracked via pg_stat_* and fixed by tuning/autovacuum or vacuumdb; replication lag is measured from pg_stat_replication and solved by WAL tuning, compression, or beefing up the replica.
AI-written summary · about
chapters (11)
- 0:00Introduction and agenda
- 1:10Critical Postgres issues overview
- 2:15Impact of database issues
- 3:18Challenges in customer environments
- 4:24Need for immediate action
- 5:30Subtransaction cache overflow
- 10:30Database corruption cases
- 25:28Autovacuum failure risks
- 42:26Streaming replication lag
- 59:49Best practices summary
- 1:04:01Q&A and closing
related talks
42mPostgres: stories that will scare you
33mPostgres Storytelling: Support in the Darkest Hour
48mProblem in PostgreSQL SLRU - And how we are optimizing it
01h 00mThe 10 Deadly PostgreSQL Sins
27mMaintaining Large Tables in PostgreSQL
31m5 Wrong Hypotheses about PostgreSQL Multi-Transaction Locks
38mWhen it All Goes Wrong: Database Incident Response Dos and Don'ts
37mWhen it all goes Wrong (with Postgres)