Re: REPACK (CONCURRENTLY) rewrites tables marked with user_catalog_table

Hi,

On Thu, Aug 27, 2026 at 7:22 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> IIUC this can cause problems for logical replication consumers, since the
> CONCURRENTLY path doesn't go through the rewriteheap.c machinery like the
> non-concurrent path does:
>
> CREATE TABLE t (a INT PRIMARY KEY, b TEXT) WITH (user_catalog_table = true);
> ALTER TABLE t ALTER COLUMN b TYPE varchar(100); -- correctly fails
> REPACK (CONCURRENTLY) t; -- should fail but doesn't
>
> I believe the fix for v19 is to add a check for
> RelationIsUsedAsCatalogTable() in check_concurrent_repack_requirements()
> (plus a corresponding update to the list of CONCURRENTLY limitations in the
> docs).

That's correct. I verified that concurrent repack doesn't write the
pg_logical/mappings files, which decoding later needs to correctly map
the old tuple locations to the new ones after a rewrite, unlike
non-concurrent CLUSTER, VACUUM FULL and REPACK on a user catalog
table. I think restricting user catalog tables, rather than making
concurrent repack support them, is the right choice at this point in
the release cycle.

Please find attached a patch with the suggested doc change. I didn't
add a test, I don't think we need one.

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