| From: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| 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-24 11:50:03 |
| Message-ID: | CAH5HC94skCWO58iFf=JOXQyUH+5Kb9we9Me8VHTvBzy3h19vZg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> > #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.
> >
>
I missed this as I had not tried with asserts enabled. I considered
the following approaches to fix this :
1. By changing the check to allow constr_flag &
INDEX_CONSTR_CREATE_DEFERRABLE to be non-zero even if
INDEX_CREATE_ADD_CONSTRAINT was not set. This seemed unsafe.
2. Adding a new flag to the function to specially allow
INDEX_CONSTR_CREATE_DEFERRABLE for the case when the index was being
copied.
3. Adding a new flag but using that to determine whether to set
indimmediate to true or not. This way constr_flags still follows the
contract that it will only be used when a constraint is being created.
I ended up picking the 3rd approach and created a new index creation
flag INDEX_CREATE_IS_DEFERRABLE_COPY. Now indimmediate is set if
either INDEX_CONSTR_CREATE_DEFERRABLE is set in constr_flags or
INDEX_CREATE_IS_DEFERRABLE_COPY is set in flags. This looked a little
extra code but I think it's cleaner as it allows constr_flags to be
only used when a new constraint is created. And a reader can see that
there are two possible reasons for setting indimmediate to false.
I'm attaching the v2 patch with this change. Please let me know what you think.
Thanks
Nitin Motiani
Google
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-propagation-of-indimmediate-flag-in-index_cre.patch | application/x-patch | 9.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhijie Hou (Fujitsu) | 2026-07-24 12:03:18 | RE: Collect ALTER PUBLICATION commands for event triggers |
| Previous Message | Zsolt Parragi | 2026-07-24 11:10:35 | Re: convert various variables to atomics |