From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@kurilemu.de>
cc: Chao Li <li.evan.chao@gmail.com>,
    Matthias van de Meent <boekewurm+postgres@gmail.com>,
    Nathan Bossart <nathandbossart@gmail.com>,
    pgsql-hackers@postgresql.org
Subject: Re: REPACK (CONCURRENTLY) fails when replica identity index is
 dropped
In-reply-to: <aqKC6K_QO0OEv3gy@alvherre.pgsql>
References: <aqKC6K_QO0OEv3gy@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@kurilemu.de>
   message dated "Thu, 10 Sep 2026 12:22:52 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <45512.1789063796.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Sep 2026 20:09:56 +0200
Message-ID: <45513.1789063796@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/45513.1789063796%40localhost>
Precedence: bulk

Alvaro Herrera <alvherre@kurilemu.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 p=
g_upgrade
> > > fixes them because pg_dump does not issue "ALTER TABLE ... REPLICA I=
DENTITY
> > > USING INDEX ..." if there is not identity index. Thus after pg_resto=
re,
> > > 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 thi=
nk
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