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
signature.asc
Description: PGP signature
