Nick Cleaton wrote on 2/1/22 12:43 AM:We've very occasionally seen something similar with a script that did CREATE INDEX CONCURRENTLY, RENAME INDEX and DROP INDEX CONCURRENTLY on the primary, but not since we upgraded from 9.4 to 12 and switched to using REINDEX CONCURRENTLY. In our case the OID in the error belonged to the index that was dropped, not the table.
I think It'd be worth noting the OIDs of the table and its indexes before each run, so that you can tell if it belongs to an index in your case.
Oh it most certainly did. (We validated it in other testing, and the test we ran had pg_repack only working on indices anyway.)
It's good to hear you don't see any such issues using SQL commands. Have you tried using a simple REINDEX CONCURRENTLY?