REPACK (CONCURRENTLY) fails when replica identity index is dropped
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253581psql -h localhost -U postgresBuilt from patchset v7 (message #7), September 11, 2026 at 11:03 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253581_7 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253581_7 && git checkout t253581_7Patchset v7 (message #7) is on t253581_7
I don't fully understand the mechanics of this one, but here is a
reproducer:
CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
INSERT INTO t SELECT g, g, repeat('x', 1000) FROM generate_series(1, 1000000) g;
CREATE UNIQUE INDEX i ON t (a);
ALTER TABLE t REPLICA IDENTITY USING INDEX i;
DROP INDEX i;
REPACK (CONCURRENTLY) t;
-- in a separate session, while REPACK is still running
DELETE FROM t WHERE a = 1;
This produces the following ERROR from the REPACK command:
ERROR: incomplete delete info
CONTEXT: slot "pg_repack_34213", output plugin "pgrepack", in the change callback, associated LSN 0/A6CC1ED0
REPACK decoding worker
I think this can be addressed by verifying the index exists in
check_concurrent_repack_requirements() and erroring out if it doesn't.
--
nathan
On Thu, 27 Aug 2026 at 20:26, Nathan Bossart <nathandbossart@gmail.com> wrote:
I don't fully understand the mechanics of this one, but here is a
reproducer:CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
INSERT INTO t SELECT g, g, repeat('x', 1000) FROM generate_series(1, 1000000) g;
CREATE UNIQUE INDEX i ON t (a);
ALTER TABLE t REPLICA IDENTITY USING INDEX i;
DROP INDEX i;
REPACK (CONCURRENTLY) t;-- in a separate session, while REPACK is still running
DELETE FROM t WHERE a = 1;This produces the following ERROR from the REPACK command:
ERROR: incomplete delete info
CONTEXT: slot "pg_repack_34213", output plugin "pgrepack", in the change callback, associated LSN 0/A6CC1ED0
REPACK decoding workerI think this can be addressed by verifying the index exists in
check_concurrent_repack_requirements() and erroring out if it doesn't.
I think the issue is caused by the following: REPACK's check has the
incorrect assumption that REPLICA IDENTITY USING INDEX either reverts
to DEFAULT or falls back to the behaviour of DEFAULT if the identity
index gets dropped, and thus uses GetRelationIdentityOrPK(), which
hides a lack of replica identity index. The issue shows up due to the
following garden path of data flows:
1. A table with REPLICA IDENTITY USING INDEX doesn't fall back to
REPLICA IDENTITY DEFAULT once the identity index is dropped.
2. In the catcache, the table won't fall back to rd_replidindex =
pkeyIndex when replident='i', but instead will set
rd_replidindex=InvalidOid.
See the tail end of RelationGetIndexList.
3. Then, in heap_delete, it calls ExtractReplicaIdentity() to find the
key of the deleted tuple.
3a. ExtractR_I_() checks the identity key attributes from
RelationGetIndexAttrBitmap(..., INDEX_ATTR_BITMAP_IDENTITY_KEY), which
also only uses rd_replidindex, and doesn't fall back to the primary
key index's attributes.
3b. If ExtractR_I_() doesn't have identity key attributes, it returns NULL
3c. heap_delete thus doesn't have any logical identity attributes to
log, and treats the delete operation as any non-logical deletion when
logging the data.
4. Finally, the DELETE record gets decoded, and the logical plugin
finds out that no logical key data was included, and promptly ERRORs
out.
The attached patch is a blind shot that I suspect will fix the issue.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
On Aug 28, 2026, at 03:31, Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
On Thu, 27 Aug 2026 at 20:26, Nathan Bossart <nathandbossart@gmail.com> wrote:
I don't fully understand the mechanics of this one, but here is a
reproducer:CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
INSERT INTO t SELECT g, g, repeat('x', 1000) FROM generate_series(1, 1000000) g;
CREATE UNIQUE INDEX i ON t (a);
ALTER TABLE t REPLICA IDENTITY USING INDEX i;
DROP INDEX i;
REPACK (CONCURRENTLY) t;-- in a separate session, while REPACK is still running
DELETE FROM t WHERE a = 1;This produces the following ERROR from the REPACK command:
ERROR: incomplete delete info
CONTEXT: slot "pg_repack_34213", output plugin "pgrepack", in the change callback, associated LSN 0/A6CC1ED0
REPACK decoding workerI think this can be addressed by verifying the index exists in
check_concurrent_repack_requirements() and erroring out if it doesn't.I think the issue is caused by the following: REPACK's check has the
incorrect assumption that REPLICA IDENTITY USING INDEX either reverts
to DEFAULT or falls back to the behaviour of DEFAULT if the identity
index gets dropped, and thus uses GetRelationIdentityOrPK(), which
hides a lack of replica identity index. The issue shows up due to the
following garden path of data flows:1. A table with REPLICA IDENTITY USING INDEX doesn't fall back to
REPLICA IDENTITY DEFAULT once the identity index is dropped.
2. In the catcache, the table won't fall back to rd_replidindex =
pkeyIndex when replident='i', but instead will set
rd_replidindex=InvalidOid.
See the tail end of RelationGetIndexList.
3. Then, in heap_delete, it calls ExtractReplicaIdentity() to find the
key of the deleted tuple.
3a. ExtractR_I_() checks the identity key attributes from
RelationGetIndexAttrBitmap(..., INDEX_ATTR_BITMAP_IDENTITY_KEY), which
also only uses rd_replidindex, and doesn't fall back to the primary
key index's attributes.
3b. If ExtractR_I_() doesn't have identity key attributes, it returns NULL
3c. heap_delete thus doesn't have any logical identity attributes to
log, and treats the delete operation as any non-logical deletion when
logging the data.
4. Finally, the DELETE record gets decoded, and the logical plugin
finds out that no logical key data was included, and promptly ERRORs
out.The attached patch is a blind shot that I suspect will fix the issue.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
<v1-0001-Repack-Fix-replica-identity-index-check.patch>
After dropping the index, pg_class.relreplident is still 'i', but the corresponding pg_index entry is deleted, so the table is left in a stale state. If we only check whether the REPLICA IDENTITY index is valid in REPACK, that prevents REPACK from starting, but doesn’t resolve the stale state itself.
We cannot assume the intended replacement replica identity after removing an explicitly selected index. For example, the user might want DEFAULT, FULL, or maybe another index. Should we instead prevent dropping of an index while it is used as REPLICA IDENTITY?
The attached diff makes a change in the direction, like this:
```
evantest=# CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
CREATE TABLE
evantest=# CREATE UNIQUE INDEX i ON t (a);
CREATE INDEX
evantest=# ALTER TABLE t REPLICA IDENTITY USING INDEX i;
ALTER TABLE
evantest=# DROP INDEX i;
ERROR: cannot drop index "i" because it is used as replica identity
HINT: Use ALTER TABLE ... REPLICA IDENTITY to change the table's replica identity first.
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Hi Matthias,
Thanks for digging into this. I agree with the direction of v1: the check
should use RelationGetReplicaIndex() so it matches what logical decoding
actually requires, rather than GetRelationIdentityOrPK(), which falls back
to the primary key while decoding does not. That mismatch is exactly what
lets a table with a since-dropped REPLICA IDENTITY USING INDEX slip past the
check and then fail during catch-up with "incomplete delete info".
Two problems with the way v1 restructures the deferrable-primary-key case,
though -- it moves that special case out of the "no identity index" branch
and turns it into an unconditional "must have a non-deferrable PK" test:
1) It now rejects a valid, repackable table. With an explicit replica
identity index and no primary key, ident_idx is valid, so we skip the
first error; but RelationGetPrimaryKeyIndex(rel, false) is InvalidOid, so
the second check fires:
CREATE TABLE rt (a int not null, b text);
CREATE UNIQUE INDEX rt_a ON rt(a);
ALTER TABLE rt REPLICA IDENTITY USING INDEX rt_a;
REPACK (CONCURRENTLY) rt;
-- master: ok
-- v1: ERROR: cannot execute REPACK (CONCURRENTLY) on relation "rt"
-- DETAIL: ... does not support deferrable primary keys.
-- HINT: Use ALTER TABLE ... REPLICA IDENTITY USING INDEX ...
The table has no primary key at all (deferrable or otherwise), and the
hint suggests doing exactly what it already did.
2) The genuine deferrable case loses its message. For a table with a
deferrable PK and no explicit identity, RelationGetReplicaIndex() is
InvalidOid, so it hits the first (generic) error, and the deferrable-
specific message in the second check is now unreachable.
So the deferrable special case ends up firing for the wrong table and not
firing for the right one. I think it just wants to stay a reason for "no
identity index", i.e. inside that branch, and the fix can be the one-line
swap that keeps the original structure:
- ident_idx = GetRelationIdentityOrPK(rel);
+ ident_idx = RelationGetReplicaIndex(rel);
if (!OidIsValid(ident_idx))
{
if (OidIsValid(rel->rd_pkindex) && rel->rd_ispkdeferrable)
ereport(... deferrable primary keys ...);
ereport(... no identity index ...);
}I built that and checked the three cases: explicit identity index without a
PK still repacks, a dropped-identity-index table is now refused up front
with "no identity index" (instead of failing mid-repack), and the deferrable
case keeps its own message. Happy to post it as a patch if useful.
On Chao's suggestion to block DROP INDEX of a replica identity index: it's a
reasonable hardening idea, but I don't think it removes the need to fix the
check here. The guard lives in RemoveRelations(), so it only covers the
DROP INDEX command -- an index backing a constraint is still dropped through
the dependency path, so e.g.
ALTER TABLE t DROP CONSTRAINT t_a_key; -- t_a_key is the RI index
leaves relreplident = 'i' with the index gone, same stale state. (I
confirmed that on a build with that patch.) And pre-existing tables in that
state, from before such a change or via pg_upgrade, would still reach the
old code path. So REPACK needs to handle the state gracefully regardless;
blocking the drop, if wanted, seems like a separate discussion (and a
behavior change, since dropping such an index is allowed today).
For what it's worth I also agree with the note that decoding can't just fall
back to the PK -- the identity is a contract with subscribers, and an 'i'
table deliberately isn't using the PK, so substituting it would log the
wrong columns.
On Fri, Aug 28, 2026 at 3:31 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
On Thu, 27 Aug 2026 at 20:26, Nathan Bossart <nathandbossart@gmail.com> wrote:
I don't fully understand the mechanics of this one, but here is a
reproducer:CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
INSERT INTO t SELECT g, g, repeat('x', 1000) FROM generate_series(1, 1000000) g;
CREATE UNIQUE INDEX i ON t (a);
ALTER TABLE t REPLICA IDENTITY USING INDEX i;
DROP INDEX i;
REPACK (CONCURRENTLY) t;-- in a separate session, while REPACK is still running
DELETE FROM t WHERE a = 1;This produces the following ERROR from the REPACK command:
ERROR: incomplete delete info
CONTEXT: slot "pg_repack_34213", output plugin "pgrepack", in the change callback, associated LSN 0/A6CC1ED0
REPACK decoding workerI think this can be addressed by verifying the index exists in
check_concurrent_repack_requirements() and erroring out if it doesn't.I think the issue is caused by the following: REPACK's check has the
incorrect assumption that REPLICA IDENTITY USING INDEX either reverts
to DEFAULT or falls back to the behaviour of DEFAULT if the identity
index gets dropped, and thus uses GetRelationIdentityOrPK(), which
hides a lack of replica identity index. The issue shows up due to the
following garden path of data flows:1. A table with REPLICA IDENTITY USING INDEX doesn't fall back to
REPLICA IDENTITY DEFAULT once the identity index is dropped.
2. In the catcache, the table won't fall back to rd_replidindex =
pkeyIndex when replident='i', but instead will set
rd_replidindex=InvalidOid.
See the tail end of RelationGetIndexList.
3. Then, in heap_delete, it calls ExtractReplicaIdentity() to find the
key of the deleted tuple.
3a. ExtractR_I_() checks the identity key attributes from
RelationGetIndexAttrBitmap(..., INDEX_ATTR_BITMAP_IDENTITY_KEY), which
also only uses rd_replidindex, and doesn't fall back to the primary
key index's attributes.
3b. If ExtractR_I_() doesn't have identity key attributes, it returns NULL
3c. heap_delete thus doesn't have any logical identity attributes to
log, and treats the delete operation as any non-logical deletion when
logging the data.
4. Finally, the DELETE record gets decoded, and the logical plugin
finds out that no logical key data was included, and promptly ERRORs
out.The attached patch is a blind shot that I suspect will fix the issue.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
--
Regards,
Ewan Young
Chao Li <li.evan.chao@gmail.com> wrote:
After dropping the index, pg_class.relreplident is still 'i', but the corresponding pg_index entry is deleted, so the table is left in a stale state. If we only check whether the REPLICA IDENTITY index is valid in REPACK, that prevents REPACK from starting, but doesn’t resolve the stale state itself.
We cannot assume the intended replacement replica identity after removing an explicitly selected index. For example, the user might want DEFAULT, FULL, or maybe another index. Should we instead prevent dropping of an index while it is used as REPLICA IDENTITY?
The attached diff makes a change in the direction, like this:
```
evantest=# CREATE TABLE t (a INT PRIMARY KEY, b INT, c TEXT);
CREATE TABLE
evantest=# CREATE UNIQUE INDEX i ON t (a);
CREATE INDEX
evantest=# ALTER TABLE t REPLICA IDENTITY USING INDEX i;
ALTER TABLE
evantest=# DROP INDEX i;
ERROR: cannot drop index "i" because it is used as replica identity
HINT: Use ALTER TABLE ... REPLICA IDENTITY to change the table's replica identity first.
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.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
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. I don't
think such a behavioral change is backpatchable though, so let's confine
us to pg19. The finding that pg_upgrade doesn't preserve the broken
state is good, because we don't have to handle it in any particular way.
I think the proposed implementation is flawed though, because the index
might be dropped indirectly (maybe an opclass or extension is dropped
CASCADE). I think it should happen somewhere in performDeletion() and
friends, which is to say it should happen during doDeletion(), thus the
check should be in index_drop().
Thanks
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers
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?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
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 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
On Sep 11, 2026, at 02:09, Antonin Houska <ah@cybertec.at> wrote:
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 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]/messages/by-id/CAA4eK1KHA-mkvtRPKsE-er8ePOnEu59_hxApaQKtr2=2GNOEQA@mail.gmail.com. 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]: /messages/by-id/CAA4eK1KHA-mkvtRPKsE-er8ePOnEu59_hxApaQKtr2=2GNOEQA@mail.gmail.com
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
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
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] /messages/by-id/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
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)
On 2026-Aug-28, Ewan Young wrote:
Thanks for digging into this. I agree with the direction of v1: the check
should use RelationGetReplicaIndex() so it matches what logical decoding
actually requires, rather than GetRelationIdentityOrPK(), which falls back
to the primary key while decoding does not. That mismatch is exactly what
lets a table with a since-dropped REPLICA IDENTITY USING INDEX slip past the
check and then fail during catch-up with "incomplete delete info".
Right, thanks for the analysis. I agree with this fix (and I can
confirm that an isolationtester spec for the scenario reproduces the
issue as Nathan reported and no longer does anything weird after the
fix), so I have pushed it. I threw in a test case that verifies that
the sequence is rejected.
Now, IMO the behavior of RelationGetIndexList in this regard is broken:
I think it should set up the PK as replica identity when it's been set
to an index which no longer exists. That allows this to work correctly,
and I can see no downside, but didn't spend too much time on that. I'm
not going to propose changing that in pg19, though. We could also
entertain the idea of switching relreplident back to DEFAULT or just
failing the DROP INDEX outright, but of course only for pg20.
Thanks!
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"El destino baraja y nosotros jugamos" (A. Schopenhauer)