| 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
| 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 |