> On Sep 11, 2026, at 02:09, Antonin Houska <[email protected]> wrote:
>
> Alvaro Herrera <[email protected]> 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=2gno...@mail.gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
