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

On Sun, Jul 26, 2026 at 06:12:27PM +0900, Michael Paquier wrote:
> 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.

I have looked at the patch, and here are some comments/fixes:
- IS_DEFERRABLE_COPY feels confusing, and it is inconsistent with the
other option names. I have settled to a simpler CREATE_DEFERRABLE,
meaning indimmediate=false for the copy when the option is set.
- Let's avoid a hardcoded sleep in the isolation test. With 10s, I
suspect that this is going to be unstable in the buildfarm. 0.1s
should not be noticeable on a fast machine, but let's just make that
faster and reliable with an injection point. We just need one after
the phase 2, waiting while we perform some writes that break the
constraint (result would be to not break the constraint, of course,
due to the indimmediate).
- We can do the same test in less sessions and less steps. I was able
to get down to 2 sessions. Without the fix, we report immediately a
diff with the constraint breaking.

Attached is my result, that I intend to backpatch. Test is for v17~.
No time to edit the commit message yet, sorry, I get that it is
confusing with the new flag name. :p

Thanks,
--
Michael