Re: scary patch contest

On Tue, Aug 25, 2026 at 9:29 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> 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.

Very well said, +1.

I also think that those are complex features which are much more complex and
that's why nobody probably tried to solve those problems for years (decades),
which caused avalanche of 3rd party solutions in the first place, which
caused even more hairy issues.

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

General idea: I never fully understood why we couldn't also mark some features
as bleeding edge / experimental / kind of developer preview if there's some
doubt (some things like 'debug_io_direct' and recent
'debug_logical_replication_streaming' come to mind and already doing this;
one could have GUCs to unlock some experimental stuff for the brave ones.
E.g. in the case debug_io_direct it's pretty clear that that Direct I/O was
never finished, yet it's there, which is awesome. It's just the naming
('debug_' prefix) that doesn't really fit. techpreview_%s IMHO would be
way better to unlock certain stuff.

-J.