Bharath Rupireddy <[email protected]> wrote: > Hi, > > On Thu, Aug 27, 2026 at 7:22 AM Nathan Bossart <[email protected]> > 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.
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. -- Antonin Houska Web: https://www.cybertec-postgresql.com
