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

Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:

> On Sep 11, 2026, at 02:09, Antonin Houska <ah(at)cybertec(dot)at> wrote:

> > Alvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> >
> > > 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.

> +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

I said "broken replication", but actually the missing replica identity index
triggers error even on the *primary*:

postgres=# delete from a where i=1;
ERROR: cannot delete from table "a" because it does not have a replica identity and publishes deletes
HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER
TABLE.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com