Andres Freund wrote on 1/31/22 1:54 PM:
> pg_repack modifies catalogs in an unsupported way, so it's not surprising
> you'd see some odd effects. Postgres locking and visibility logic doesn't know
> about what pg_repack is doing, so it can't enforce correct semantics. I'd
> assume that the repack developers haven't gotten the locking logic quite right
> someplace.
So that all make sense to me, except that - surprise! - it turns out
we're seeing the same behavior if we leave pg_repack out of it and just
do a REINDEX TABLE CONCURRENTLY in a loop on the primary node. Again,
reliably within 30 minutes, the select on the secondary will fail with
an OID error, but not on the primary.
Sorry, I should have led with this more vanilla test case, but I didn't
think to try it till Nick Cleaton reminded me that PG12 brought us
REINDEX TABLE CONCURRENTLY.