HN

Comments (124)

• Menu

  CharlesW
  > This year is going to be different. PostgreSQL 19 most likely won’t be released until November… […] So, what happened? The short answer is that LLMs happened. […] There’s a huge amount of code, and that code contains a huge number of bugs. […] What’s different now is that it’s become vastly easier to find those bugs.This seems…good?That it might disrupt the project's "traditional" release cadence a bit doesn't seem terribly bad in light of the alternative, which is shipping another major update with bugs which have apparently haunted the codebase for some time.
• Menu

  tibbar
  I did a little AI-assisted bug-hunting in Postgres this summer in between jobs, and the haul was staggering. Multiple serialization anomalies (eg [0] [1] [2]), foreign key integrity issues ([3] [4]), planner correctness bugs such as [5]. Various CVE-worthy vulnerabilities. An unfixable timezone bug [6]. The list got so long that I had to triage what I even had time to report, and settled for a dozen or two out of hundreds of candidates. Now imagine the entire world doing this.[0] Write skew observed under serializable isolation: https://www.postgresql.org/message-id/flat/CA+COZaBo+ZpKgMvx...[1] Serializable anomaly: duplicate primary keys: https://www.postgresql.org/message-id/flat/CA+COZaBOiiRPmEfX...[2] SERIALIZABLE can commit write skew after SSI summarization: https://www.postgresql.org/message-id/flat/CA+COZaCtK=UQbeQw...[3] Fix temporal foreign key validation of pre-existing rows https://www.postgresql.org/message-id/flat/CA+COZaChq_ukm2o7...[4] Lost lock during toasting allows FK violation https://www.postgresql.org/message-id/flat/CA+COZaC-2-GQabq+...[5] Partition pruning can incorrectly exclude a RANGE default partition https://www.postgresql.org/message-id/flat/CA+COZaDXrfTaBjLE...[6] timestamp vs. timestamptz comparisons inconsistently ordered under DST : https://www.postgresql.org/message-id/flat/c22286ad6268347c6...
• Menu

  hopa
  I feel like AI is amazing for read only “search” tasks (query this, look for bugs, find vulnerabilities) but it’s not quite as good for “write” tasks like “add this feature”. Search tasks are easily verified, code changes are much harder to verify
• Menu

  droppedasbaby
  I guess the real challenge is figuring out how to scale verification, cause discovery isn't the bottleneck anymore. Generating more bug reports doesn't necessarily translate into faster fixes if the same small group of maintainers still have to validate the reports, review fixes, etc.
• alexpadula
  Makes sense. Code base is over 30 years old. Lot's of hands went into shaping it. There will be bugs as not one contributor as the entire codebase in their head. The testing is where bugs should be caught. Not by ones knowledge. I actually think there will be more bugs that come out of nowhere either found by humans or automation.
• flakes
  Most of the parent comments in this thread did not seem to understand the article. So here’s the tl;drPostgres release is delayed due to the quality bar getting raised. New features are getting more eyeballs, and therefore leading to more rollbacks. Pre-existing releases are getting bug reports and backported fixes at much higher rate. Bug fixing might be taking away time from feature development, but does harden the codebase. LLM usage seems to have been a net positive.
• anon
  undefined
• kmkrworks
  I absolutely think that this is fantastic. LLMs are widely and so, everyone and their grandma has the capability to compromise on any system. We need to be more proactive on fixing bugs.
• Menu

  dabinat
  If software as mature and widely-used as Postgres has this level of hidden bugs, what about the average software product?
• Menu

  ta93754829
  "it's AI's fault"I missed when AI became accountable for Postgres releases, when did that happen?
• flossly
  “A wizard is never late, nor is he early; he arrives precisely when he means to” -- Gandalf
• ares623
  Now, riddle me this. Does this mean productivity is up or down for the Postgres team?
• Menu

  LoganDark
  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.
• Menu

  27183
  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.
• Menu

  bamboozled
  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.
• hujun236
  [flagged]
• minfazhai
  [flagged]
• nimchimpsky
  [dead]
• Menu

  ltbarcly3
  I have found major bugs in late beta's of postgres long before AI came along. I found a bug where malformed json would segfault the entire server (a segfault in a server process forces the entire cluster to shut down by design) when using jsonb in a release candidate once. They fixed it rather than ripping the entire feature out.https://www.postgresql.org/message-id/20140818195634.2543.56...It seems quite possible that someone wants to make it seem like LLMs are causing problems by over-reacting to things that could just be fixed, or delay the release slightly (or maybe waiting until late before a release to kill features they don't like?) Whatever it is, this seems like a dysfunctional process.
• Menu

  meow9
  I’m still amazed that with all the vibe coding, no one has created a Postgres alternative
• Menu

  nektro
  postgres is mature database used the world over allegedly about to be on major version 19. how has the time not been spent already to get rid of the bugs?
• xlayn
  I sometimes think that the world would need to do a "snow leopard" release of everything... to unit test, to fix... and then we will be able to move forward... but AiMaxSlopIt will result in those situations where you have to rollback or redo from scratch parts... because it's unmantainable because it's bad... it's spread everywhere and "the map" is not there.Anecdote, I did a travel across USA and when I was looking for a hotel, if you go from apple maps, to website, to try to book, the "load browser" in the maps... could end in states where you could not go back because back is get out of where you are and go back to the start of the map... and was a terrible experience... then you turbo charge it with "implement game changer UI improvements for the new bar on UI design" goal of some guy with enough power to make damage... and you end with softslop (or is it sloprosoft?)