Re: Adding REPACK [concurrently]

Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:

> Hello!
>
> On Fri, Oct 31, 2025 at 12:17 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > Here's a new installment of this series, v25, including the CONCURRENTLY
> > part, which required some conflict fixes on top of the much-changed
> > v24-0001 patch.
>
> > * cluster.c
> > * CLUSTER a table on an index. This is now also used for VACUUM FULL.

ok

> Should we add something about repack here?
>
> > ii_ExclusinOps
> typo here.

ok

> > * index is inserted into catalogs and needs to be built later on.
> Now it is only in case concurrently == true

ok

> > * Build the index information for the new index. Note that rebuild of
> > * indexes with exclusion constraints is not supported, hence there is no
> > * need to fill all the ii_Exclusion* fields.
>
> Now the function supports its in !concurrently mode. Should we fill
> ii_Exclusion? Also, it says
>
> > If !concurrently, ii_ExclusinOps is currently not needed.

> But it is not clear - why not?

Right, makeIndexInfo() needs to be adjusted.

>
> > newInfo = makeIndexInfo(oldInfo->ii_NumIndexAttrs,
> > oldInfo->ii_NumIndexKeyAttrs,
> > oldInfo->ii_Am,
> > indexExprs,
> > indexPreds,
> > oldInfo->ii_Unique,
> > oldInfo->ii_NullsNotDistinct,
> > false, /* not ready for inserts */
> > true,
> > indexRelation->rd_indam->amsummarizing,
> > oldInfo->ii_WithoutOverlaps);
>
> Is it ok we pass isready == false if !concurrent?
> Also, we pass concurrent == true even if concurrently == false - feels
> strange and probably wrong.

You're right, both arguments are wrong.

> > This difference does has no impact on XidInMVCCSnapshot().
> Should it be "This difference has no impact"?

ok

> > * pgoutput_cluster.c
> > * src/backend/replication/pgoutput_cluster/pgoutput_cluster.c
> it is pgoutput_trepack.c :)

ok

I'll fix all the problems in the next version. Thanks!

--
Antonin Houska
Web: https://www.cybertec-postgresql.com