Re: REPACK (CONCURRENTLY) fails when replica identity index is dropped

On 2026-Sep-01, Antonin Houska wrote:

> I agree that the core issue is that we allow dropping an index that is being
> used as replica identity.
>
> Regarding catalog entries already broken this way, it appears that pg_upgrade
> fixes them because pg_dump does not issue "ALTER TABLE ... REPLICA IDENTITY
> USING INDEX ..." if there is not identity index. Thus after pg_restore,
> pg_class(relreplident) becomes REPLICA_IDENTITY_DEFAULT.

I agree that disallowing the drop is a sensible thing to do. I don't
think such a behavioral change is backpatchable though, so let's confine
us to pg19. The finding that pg_upgrade doesn't preserve the broken
state is good, because we don't have to handle it in any particular way.

I think the proposed implementation is flawed though, because the index
might be dropped indirectly (maybe an opclass or extension is dropped
CASCADE). I think it should happen somewhere in performDeletion() and
friends, which is to say it should happen during doDeletion(), thus the
check should be in index_drop().

Thanks

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers