pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedFrom: Alvaro Herrera <alvherre@kurilemu.de>
To: Antonin Houska <ah@cybertec.at>
Cc: Chao Li <li.evan.chao@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: REPACK (CONCURRENTLY) fails when replica identity index is dropped
Date: Fri, 11 Sep 2026 11:05:38 +0200
Message-ID: <aqO6Y_oSjkgtihz0@alvherre.pgsql> (raw)
In-Reply-To: <10924.1789113986@localhost>
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)
view thread (12+ messages) latest in thread
Message-ID: <aqO6Y_oSjkgtihz0@alvherre.pgsql>
Permalink: ../aqO6Y_oSjkgtihz0@alvherre.pgsql/
Also on: postgresql.org/message-id/aqO6Y_oSjkgtihz0@alvherre.pgsql
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@kurilemu.de, ah@cybertec.at, li.evan.chao@gmail.com, boekewurm+postgres@gmail.com, nathandbossart@gmail.com
Subject: Re: REPACK (CONCURRENTLY) fails when replica identity index is dropped
In-Reply-To: <aqO6Y_oSjkgtihz0@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox