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

> On Sep 11, 2026, at 02:09, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> Alvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
>> On 2026-Sep-01, Alvaro Herrera wrote:
>>
>>> 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.
>>
>> Actually, wouldn't it make more sense to reset the replica identity back
>> to 'd' when the index is dropped, as in the attached patch?
>
> Even though users probably do not drop the identity index too often, I think
> it's possible that someone tries to drop an index that seems to be
> unnecessary, but forgets that it's in use by logical replication. In such
> case, I tend to consider ERROR better response than broken replication.
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com

+1

Actually, there was a similar discussion in [1]. In that case, the question was whether setting a table to UNLOGGED should fail when the table is in a publication’s EXCEPT list, or whether PG should silently remove the table from the EXCEPT list and issue a notice to the user. Most people in that discussion, including Amit, seemed to prefer failing the operation. From a user-experience and design-consistency perspective, I think these two cases are quite similar.

[1] https://postgr.es/m/CAA4eK1KHA-mkvtRPKsE-er8ePOnEu59_hxApaQKtr2=2GNOEQA@mail.gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/