Re: scary patch contest

On Wed, Aug 26, 2026 at 4:01 AM Jakub Wartak
<jakub(dot)wartak(at)enterprisedb(dot)com> wrote:
>
> 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 disagree with this. The unsatisfactory state of alternatives is not
a reason to ship code in core Postgres that we don't feel is ready.
Something can be worth having but not be ready. And this discussion
isn't about whether or not the feature is a good idea but rather about
whether the feature should be shipped to users now.

I am not arguing that REPACK CONCURRENTLY should be reverted. But I
wanted to weigh in on this lest we think there is broad consensus that
really wanting a feature is sufficient grounds for shipping it.

And I am not arguing against releasing minimal viable versions of
features. But I think that the design that ships should be one that we
all agree is the right first step/minimal design and not what we've
reduced the feature to to deal with a bunch of bugs and issues that
came out post-commit and wouldn't have agreed was right had it been
initially proposed.

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

There are loads of things like this in Postgres. It doesn't mean we
shouldn't tackle them. But it also doesn't mean we should reduce the
bar for what goes into core. Being somewhat better than very buggy 3rd
party solutions is not the bar for what goes into Postgres. Again, I'm
not saying REPACK CONCURRENTLY falls into that bucket, just that I
don't want this sentiment to be the consensus.

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

I don't know about debug_logical_replication_streaming but
debug_io_direct was so we could run things through the buildfarm over
the course of years to look for bugs. No one, no matter how brave,
should be using direct IO in its current state.

Separately, I'm not against the idea of protecting features behind
gucs that we aren't sure exactly how they will fare in the wild. But
that is different than taking features we feel pretty sure have bugs
and releasing them for people to just try them out. Those people can
test master.

- Melanie