Re: REPACK (CONCURRENTLY) doesn't check the table AM - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: REPACK (CONCURRENTLY) doesn't check the table AM
Date
Msg-id CALj2ACVJhM3OARtD_eSVVn9KDCpyNUTipEAzkZnO1idMEFEcFQ@mail.gmail.com
Whole thread
Responses Re: Support EXCEPT for ALL SEQUENCES publications
List pgsql-hackers
Hi,

On Thu, Aug 27, 2026 at 12:57 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.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.

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

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: pg_*_advice: tsv load failure, etc.
Next
From: Mihail Nikalayeu
Date:
Subject: Logical replication can lose an update after concurrent index invalidation