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. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
v1-0001-Restrict-concurrent-repack-on-user-catalog-tables.patch
Description: Binary data
