Top
Best
New

Posted by soheilpro 2 days ago

Postgres 19 is late because so many more bugs are being found now(rhaas.blogspot.com)
489 points | 305 commentspage 4
BrenBarn 2 hours ago|
> given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate?

I mean, maybe just innovate less? "Innovation" is one of those words that makes me queasy nowadays. It's been true for decades that a good deal of what's touted as "innovation" is just stuff that is not actually as important as fixing what's already there. Most software releases new versions far too often for far too little reason. So overall it's good to see Postgres slowing down rather than just barreling ahead with a new release.

LoganDark 9 hours ago||
Is no one entertaining the possibility that some contributions were lower quality due to AI? I'm surprised to have only seen arguments that it's review.
StilesCrisis 8 hours ago|
If you look at the kind of bugs coming in, it's from all corners of the codebase, not just things changed in the last 1-2 years.
LoganDark 3 hours ago||
Ah, that makes more sense. Thank you!
27183 10 hours ago||
I'm not very positive on the social, technical, or intellectual impact of AI on software development. Actually, that's understating it. I think AI is basically cancer for the mind. That said, this framing gave me pause:

> The long-term picture is less clear and in some ways more troubling: given that we have forty years of bugs that humans were unable to find but LLMs are quite capable of discovering, how are we ever going to catch up, and how will PostgreSQL continue to innovate? Right now, I’m not sure. What I do know is that I, and many others, are working really hard to figure it out.

Two thoughts:

1. If the signal quality is high--the bug reports are generally valid, the submitted fixes are generally viable (if needing some attention)--then this all seems great. Pause innovation for a while, you can afford it. Focus on burning down the bug count, and resume feature development when things are more stable.

2. If the signal quality isn't good, or is sufficiently mixed that a lot of time is being wasted on low quality contributions... that's more complex. I don't know what to do about that. Maybe stop accepting contributions from unknown contributors? No idea.

From the post I'm not sure whether they're experiencing a (1) or a (2). If it's a (1) that's really interesting, and gives me some glimmer of hope for the future.

[edit] this piece of shit website won't let me reply "you're posting too fast.." so I'll respond to the two replies here (gondalez and sverhagen had basically the same point):

Yes that's a very good point. Not every valid bugfix is equivalently urgent. That's another critical dimension of quality--not burdening maintainers with pedantic bugs. This kind of contextual nuance is, coincidentally, something AI is absolutely awful at.

sverhagen 10 hours ago||
Signal quality... what is that even? The bugs may be valid, but they may also be obscure, irrelevant, low priority. A sibling thread mentioned that they had found CVE-level bugs in Postgres, and those require attention in some version of "immediately". But beyond that... not every bug needs fixing; that's a trap.
tonyhart7 9 hours ago||
"But beyond that... not every bug needs fixing; that's a trap"

this doesn't seem good attitude for critical software like database

sverhagen 8 hours ago|||
Not every part of a critical piece system is itself critical.

Seatback entertainment in aircraft are not critical. Aircraft are.

In Postgres, there are plenty low-priority, low-impact bugs. #16265, for instance, reports that the capitalization of a relation in an error message is confusing. The report got mostly ignored. And that seems not a great loss.

Dare I say, solving every bug does not make economic sense.

inglor_cz 4 hours ago||
"Seatback entertainment in aircraft are not critical."

Until it is. Swiss Air Flight 111 went down with 229 lives lost because of a new infotainment system whose electrical cables started sparkling.

Yes, not every part of a critical system is critical. Determining which is which is a complicated task, though, as parts interact. Not too long ago (and by this I mean within my lifetime), we were ignorant enough about our own bodies to think that our microbiota was almost irrelevant to our health and that bad teeth were mostly a cosmetic problem.

Back to IT, Heartbleed was caused by addition of a feature that looked as harmless as you could think of. But it wasn't.

Judging real critical-ness of bugs is hard. Yeah, capitalization of an error message is likely harmless, but I would treat, say, any buffer overflow as serious.

alexpadula 8 hours ago||||
I do tend to agree with this ( i write database internals and engines for a living _). Letting software accumulate even little bugs is not a good look. Yes prioritize but definitely don't leave the smaller things, they will just pile up and make next work even harder.
tibbar 9 hours ago||||
Old bugs are sometimes undesirable to fix because other systems/users have come to rely on their behavior.
alexpadula 8 hours ago||
That's a weird take. Do you have an example tibbar?
tibbar 7 hours ago||
Sure. This one already came up. [0]. In general, for a system like Postgres, many bugs affect only "extreme edge case" scenarios, but fixing them might create severe performance issues or require changing or removing other important features. So it's better to not fix them.

[0] https://www.postgresql.org/message-id/flat/c22286ad6268347c6...

whateveracct 7 hours ago|||
the optimal amount of fraud for a fintech is non-zero

why would the optimal amount of bugs be anything less for a database?

gondalez 10 hours ago||
Seems like a lot of these bugs have not affected end-users or tripped up maintainers. They could be trade-offs that helped get other features over the line even?

In which case maybe leaving them alone is practical?

I love fixing bugs, but your post triggered this thought so I thought I'd share.

ares623 7 hours ago||
Now, riddle me this. Does this mean productivity is up or down for the Postgres team?
bamboozled 9 hours ago||
So it seems there as a certain level of safety in obscurity that was acceptable / fine which has been lost and therefore the focus is shifting towards churning through the slop.
jimbokun 8 hours ago|
[flagged]
dang 8 hours ago||
"Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative."

https://news.ycombinator.com/newsguidelines.html

I think of you as a good HN contributor, but you've been posting a lot of unsubstantive comments lately, and breaking the site guidelines in other ways too. Can you please stop doing this, and return to using HN in the intended spirit? Your substantive, thoughtful points are welcome, but not comments like this current one, nor these (to pick a few examples):

https://news.ycombinator.com/item?id=50280377

https://news.ycombinator.com/item?id=50275967

https://news.ycombinator.com/item?id=50147625

hujun236 8 hours ago||
[flagged]
vibecodi 5 hours ago||
[flagged]
ravivarmat 5 hours ago||
[dead]
PIYUSHMSONI98 5 hours ago||
[flagged]
wiseowise 3 hours ago|
> The short answer is that LLMs happened. All software contains bugs, and PostgreSQL’s code base is large, complex, and old. Our git history – converted from CVS – now reaches back more than 30 years, and the first code was written a decade before that. There’s a huge amount of code, and that code contains a huge number of bugs. That’s always been true, and it hasn’t stopped PostgreSQL from being popular or successful. What’s different now is that it’s become vastly easier to find those bugs. Fixing them has also gotten easier, but not to the same degree.

LLMs are a gimmick, btw. This is an Anthropic marketing stunt, how much did they pay you? /s

More comments...