Live data from Hacker News

PostgreSQL production incident caused by transaction ID wraparound

sqlservercentral.com

11–13 of 13 posts

Re: PostgreSQL production incident caused by transaction ID wraparound

#11
post #10
post #8

Earlier quoted context omitted.

It's not as obvious as you think, GitLab was hit by this a few years ago. But yes, low-quality article and the SQL Server plug is in poor taste.

Many SEV-1s are “obvious”. Still feels like a kick in the stomach if your the one that was response LOLz.

I meant "obvious to anyone putting PostgreSQL in production that they have to put specific monitoring in place for this, and palliative measures"

The database shutting itself down and refusing to come back up until a full vacuum or vacuum freeze is performed, which means days of downtime, yes, that's pretty obvious indeed.

Re: PostgreSQL production incident caused by transaction ID wraparound

#12
Getting AI vibes from this article? It is strangely repetitive and meandering. Also tell-tale "It's not X, it's Y" and sort of unspecific mostly.

Also, why would you have billions of open transactions? That is the implication I got from the article as someone who doesn't know anything about Postgres.

(I use SQLite and perhaps I have Stockholm syndrome, but I like how it pushes you towards a design with small transactions, ideally entirely database-side.)

EDIT: Yeah, gptzero says AI with 100% confidence.

Re: PostgreSQL production incident caused by transaction ID wraparound

#13

Getting AI vibes from this article? It is strangely repetitive and meandering. Also tell-tale "It's not X, it's Y" and sort of unspecific mostly. Also, why would you have billions of open transactions? That is the implication I got from the article as someone who doesn't know anything about Postgres. (I use SQLite and perhaps I have Stockholm syndrome, but I like how it pushes you towards a design with small transact…

Congrats on blaming the messenger, and not bothering to understand the issue.
Post reply on HN