Re: scary patch contest

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scary patch contest
Date: 2026-08-25 19:29:16
Message-ID: 3ab26a46-b405-4f41-8b34-fbf91b41ce0b@dunslane.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2026-08-25 Tu 2:54 PM, Robert Haas wrote:
> On Tue, Aug 25, 2026 at 2:13 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>> #2 has been cut back in scope enough that I don't think we would have accepted
>>> the feature originally if it had been subject to those limitations, which IMHO
>>> is a reasonable argument for a revert but also not conclusive.
>> I don't think that is an argument for reverting, I think it's an argument for
>> blocking progress by making perfect the enemy of good.
> I'm not sure I understand what you're saying here. My guess is that
> you're arguing that we should have been willing to take REPACK
> CONCURRENTLY even if we'd known from the beginning that the
> one-at-a-time-per-cluster restriction would have been necessary. I
> would have argued against that, but perhaps I would have been wrong to
> do so, and it's certainly fair if you feel otherwise.

Given the unsatisfactory state of all the alternatives, I think it is
still worth having, modulo any remaining bugs.

>
>>> I'm pretty scared about all of #1-#3 having a long tail of bugs that we haven't
>>> found yet, in pretty critical areas.
>> I'll prepare a revert.
> My sincere intention was to start a conversation, not jump straight to
> a conclusion. If you were already half-convinced that you should be
> thinking about reverting and this pushed you over the line, I suppose
> that's fair enough. Otherwise, I think some discussion would be a good
> idea.

Agreed, let's not be hasty, even though time is now very short. I do
remember one case about 10 years ago that people told me they found
scary, but in the event it hasn't given rise to the huge number of bugs
that were predicted. I do think we need to be smarter about using LLMs
methodically to detect and test for bugs more comprehensively, not as an
alternative to human efforts but as a useful supplement.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-08-25 19:32:25 Re: datachecksums: handle invalid and dropped databases during enable
Previous Message Nathan Bossart 2026-08-25 19:25:59 Re: Crashes on a partition whose concurrent detach never finished