PostgreSQL production incident caused by transaction ID wraparound
tcp_handshaker
25 points
9 comments
April 18, 2026
Related Discussions
Found 5 related stories in 59.7ms across 4,930 title embeddings via pgvector HNSW
- Postgres Traffic Control samlambert · 17 pts · March 23, 2026 · 52% similar
- Better JIT for Postgres vladich · 143 pts · March 04, 2026 · 47% similar
- AWS engineer reports PostgreSQL perf halved by Linux 7.0, fix may not be easy crcastle · 203 pts · April 05, 2026 · 46% similar
- Keeping a Postgres Queue Healthy tanelpoder · 91 pts · April 11, 2026 · 46% similar
- What's new in Linux kernel for PostgreSQL erthalion · 21 pts · March 03, 2026 · 43% similar
Discussion Highlights (5 comments)
jffry
tl;dr: autovacuum was seen to be active during an earlier incident, assumed to be at fault, and was disabled. It was never re-enabled. The long-term implications of disabling autovacuum were not actively considered.
fallpeak
TL;DR: Devs didn't know what they were doing and turned off autovacuum and eventually it broke, then the author decided to have an AI slop out an article about the incident which may or may not have actually occurred.
plasticeagle
AI;DR Which is why it's TL;DR Boring shit article about obvious problem.
rastignack
Just monitor it and you’re done. I’ve delivered and maintained hundreds of pg instances and never faced this issue. There is so much literature about it that at some point no one even slightly skilled will face it.
throwatdem12311
TL;DR Don’t turn off auto vacuum and periodically tweak your write heavy tables so they are vacuumed regularly enough so this never happens.