Re: [PATCH v1] Fix propagation of indimmediate flag in index_create_copy

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Nitin Motiani <nitinmotiani(at)google(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH v1] Fix propagation of indimmediate flag in index_create_copy
Date: 2026-07-20 18:17:44
Message-ID: al5l0miLqp4CuG_i@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Jul-20, Nitin Motiani wrote:

> It was reported in [1] that Reindex Concurrently for indexes with
> deferrable constraints doesn't honour the deferrable constraints while
> the operations is running. And the transactions can fail because the
> constraint is enforced before commit.
>
> I'm proposing a patch here which correctly copies the flag from the
> old index to the new one. Please take a look.

Hah, that was quick, thanks! This fails the isolation tests for me
though, with this backtrace:

#4 0x00005618d76672d6 in ExceptionalCondition (
conditionName=conditionName(at)entry=0x5618d77741a8 "(constr_flags == 0) || ((flags & INDEX_CREATE_ADD_CONSTRAINT) != 0)",
fileName=fileName(at)entry=0x5618d7773e58 "../../pgsql/source/master/src/backend/catalog/index.c", lineNumber=lineNumber(at)entry=773)
at ../../pgsql/source/master/src/backend/utils/error/assert.c:65
#5 0x00005618d7271fd5 in index_create (heapRelation=heapRelation(at)entry=0x7f13e9ce85d0,
indexRelationName=indexRelationName(at)entry=0x5618fe816e58 "uq_val_ccnew", indexRelationId=indexRelationId(at)entry=0,
parentIndexRelid=parentIndexRelid(at)entry=0, parentConstraintId=parentConstraintId(at)entry=0, relFileNumber=relFileNumber(at)entry=0,
indexInfo=0x5618fe816aa8, indexColNames=0x5618fe6c8d40, accessMethodId=403, tableSpaceId=0, collationIds=0x5618fe73e2f8,
opclassIds=0x7f13e9cead80, opclassOptions=0x5618fe6c8ea0, coloptions=0x7f13e9cead9c, stattargets=0x5618fe80d748, reloptions=0, flags=140,
constr_flags=2, allow_system_table_mods=true, is_internal=false, constraintId=0x0) at ../../pgsql/source/master/src/backend/catalog/index.c:773
#6 0x00005618d727248d in index_create_copy (heapRelation=heapRelation(at)entry=0x7f13e9ce85d0, flags=flags(at)entry=140, oldIndexId=33725,
tablespaceOid=0, newName=0x5618fe816e58 "uq_val_ccnew") at ../../pgsql/source/master/src/backend/catalog/index.c:1468
#7 0x00005618d72cbd46 in ReindexRelationConcurrently (stmt=stmt(at)entry=0x5618fe712228, relationOid=relationOid(at)entry=33722,
params=params(at)entry=0x7ffcf8ab62f8) at ../../pgsql/source/master/src/backend/commands/indexcmds.c:4117
#8 0x00005618d72cd892 in ReindexTable (stmt=0x5618fe712228, params=0x7ffcf8ab62f8, isTopLevel=true)
at ../../pgsql/source/master/src/backend/commands/indexcmds.c:3227
#9 ExecReindex (pstate=pstate(at)entry=0x5618fe6c8c30, stmt=stmt(at)entry=0x5618fe712228, isTopLevel=isTopLevel(at)entry=true)
at ../../pgsql/source/master/src/backend/commands/indexcmds.c:3042

This is during the
REINDEX TABLE CONCURRENTLY reind_deferred;
execution.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them." (Freeman Dyson)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2026-07-20 18:17:57 Re: hashjoins vs. Bloom filters (yet again)
Previous Message Robert Haas 2026-07-20 18:13:04 Re: document the dangers of granting TRIGGER or REFERENCES