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

On 2026-Aug-28, Ewan Young wrote:

> Thanks for digging into this. I agree with the direction of v1: the check
> should use RelationGetReplicaIndex() so it matches what logical decoding
> actually requires, rather than GetRelationIdentityOrPK(), which falls back
> to the primary key while decoding does not. That mismatch is exactly what
> lets a table with a since-dropped REPLICA IDENTITY USING INDEX slip past the
> check and then fail during catch-up with "incomplete delete info".

Right, thanks for the analysis. I agree with this fix (and I can
confirm that an isolationtester spec for the scenario reproduces the
issue as Nathan reported and no longer does anything weird after the
fix), so I have pushed it. I threw in a test case that verifies that
the sequence is rejected.

Now, IMO the behavior of RelationGetIndexList in this regard is broken:
I think it should set up the PK as replica identity when it's been set
to an index which no longer exists. That allows this to work correctly,
and I can see no downside, but didn't spend too much time on that. I'm
not going to propose changing that in pg19, though. We could also
entertain the idea of switching relreplident back to DEFAULT or just
failing the DROP INDEX outright, but of course only for pg20.

Thanks!

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"El destino baraja y nosotros jugamos" (A. Schopenhauer)