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

On Fri, Jul 24, 2026 at 05:20:03PM +0530, Nitin Motiani wrote:
> 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.

As this is in my realm of things.. I have caught up with what you
have here.

And here I thought that we somewhat missed to set indimmediate on the
new index definition in index_concurrently_swap(), but your issue is
before even that. It is a sensible thing to do to ensure that the
initial phase of the copied index satisfies the deferred constraint of
the underlying table, limiting the reliability of the operation, as we
want the index to be reused for the constraint.

The addition of the new INDEX_ option would be at least backpatchable.
I was wondering why you needed the extra flag to begin with, but I
don't immediately see how we could enforce indimmediate properly in
the definition copy without it. Having three flags related to
deferred constraints feels a bit annoying long-term, but that really
comes down to the grammar representation, what we allow in the table
definition based on the standard, and how much space we give the
backend internals to deal with the CREATE TABLE grammar for
constraints in an equivalent way.

Side note: your patch has some useless whitespaces in index.h. I'll
study all that a bit more next week, booking a few hours.
--
Michael