Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 11 Sep 2026 11:05:38 +0200
From: Alvaro Herrera <alvherre@kurilemu.de>
To: Antonin Houska <ah@cybertec.at>
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
Message-ID: <aqO6Y_oSjkgtihz0@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <10924.1789113986@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/aqO6Y_oSjkgtihz0%40alvherre.pgsql>
Precedence: bulk

On 2026-Sep-11, Antonin Houska wrote:

> Chao Li <li.evan.chao@gmail.com> wrote:
> 
> > On Sep 11, 2026, at 02:09, Antonin Houska <ah@cybertec.at> wrote:
> 
> > > Alvaro Herrera <alvherre@kurilemu.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

I can't really disagree with this argument, but sadly, due to the way
object drop works, this is tough to implement.  If I simply throw an
error in index_drop(), all manner of things are disallowed: most curious
is probably ALTER TABLE .. SET DATA TYPE on a column of the replica
identity, because that wants to transiently drop the index so that it
can be recreated.  But of course the worst is DROP TABLE: because each
individual object deletion is carried out oblivious of every other
object deletion, we don't _know_ that the table containing the replica
identity is _also_ being dropped, so we raise an error when the replica
identity index is dropped and the whole DROP TABLE fails.

Maybe a way to do this would be to hack reportDependentObjects() to see
if a replica identity index is in there, and abort the drop if the table
is not also being dropped.  (That doesn't fix the ALTER TABLE TYPE
problem though).  This sounds too invasive to consider at this stage of
the cycle.  Going forward in pg20 we should try to implement something
like that, but it doesn't seem a good way to close the open item.

Maybe it's better to go back to Matthias original fix proposal instead,
or Ewan Young's variation thereof.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)