Re: REPACK (CONCURRENTLY) doesn't check the table AM

Hi,

On Thu, Aug 27, 2026 at 1:45 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Thu, Aug 27, 2026 at 12:57 PM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > > If the table AM doesn't support logical decoding, concurrent repack
> > > would silently lose some table data as it misses the changes
> > > happened during the rewrites.
> >
> > Yes, that's correct. I came to the same conclusion.
> >
> > > I think we should have the check for it.
> > > One idea would be to have a new table AM callback returning true if
> > > the table AM supports concurrent repack (i.e., its rmgr provides
> > > rm_decode callback), but I think it's not the right time to introduce
> > > a new table AM callback.
> >
> > Agreed. Adding a new table AM callback needs consensus and is time
> > consuming. Perhaps we can try for HEAD based on field reports that
> > require the concurrent repack feature for non-heap table AMs.
> >
> > > So restricting it to heap for v19 seems fine
> > > to me.
> >
> > +1. I will send a patch soon.
>
> Please find the attached patch. I didn't add a test, I don't think we need one.

Added the limitation to the repack docs. Please find the attached v2
patch. Sorry for the noise.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com