Re: REPACK (CONCURRENTLY) rewrites tables marked with user_catalog_table

On Mon, Aug 31, 2026 at 8:35 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Sat, Aug 29, 2026 at 8:34 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Sat, Aug 29, 2026 at 4:23 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > >
> > > Thanks! I'm just thinking about this comment:
> > >
> > > + /* The CONCURRENTLY path does not write logical rewrite mappings. */
> > >
> > > IMO it makes no sense to rewrite the logical mappings as long as REPACK
> > > (CONCURRENTLY) changes visibility information (i.e. it's MVCC-unsafe). Once we
> > > implement the MVCC-safety, we should not remove this check unless we implement
> > > the rewriting of the mappings for user catalog tables - that might also be
> > > worth mentioning in the comment.
> > >
> > > So far, I'd consider the MVCC-unsafety the primary reason to prohibit REPACK
> > > (CONCURRENTLY) (or anyother MVCC-unsafe command) on the user catalog tables,
> > > because it can make the contents of those tables invisible to the output
> > > plugin at some point.
> >
> > Thanks for pointing this out. I read the docs related to MVCC-safety
> > of concurrent repack. I reworded the comment as you suggested. Feel
> > free to suggest changes to it if any. Please find the attached v2
> > patch.
>
> Please find the attached v3 patch with a test added similar to other
> restricted error cases. Sorry for the noise.

I reviewed the patch. It's simple and I agree to add a check for user
catalog tables. I've slightly rephrased the comment in
check_concurrent_repack_requirements() to clarify the reason why
REPACK (CONCURRENTLY) doesn't support user catalog tables while it
does for normal tables even though it's a MVCC-unsafe operation. Also
updated the commit message as well. Please review it.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com