On 2026-08-26 We 10:11 AM, Melanie Plageman wrote:
On Wed, Aug 26, 2026 at 4:01 AM Jakub Wartak
<[email protected]> wrote:
On Tue, Aug 25, 2026 at 9:29 PM Andrew Dunstan <[email protected]> wrote:
On 2026-08-25 Tu 2:54 PM, Robert Haas wrote:
On Tue, Aug 25, 2026 at 2:13 PM Daniel Gustafsson <[email protected]> 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 didn't mean to say that the process has been satisfactory. I was
merely commenting on where we are now, which I think is strictly better
than where we would be without it, albeit that is has limitations we'd
much rather not have.
If we thought this was a barrier to getting to an implementation without
those limitations then there would be a good case for reversion.
I agree with your third paragraph, that states the ideal process. Sadly,
things sometime get a bit messier than that.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
