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

>
> You may note that I have used the word "tentatively" regarding the
> backport of the test. In v17~v19, injection point waits depend on
> condition variables, that depend on DSMs, that have a dependency with
> cleanup actions not happening correctly outside of transaction
> contexts as far as I know. We're dealing with a wait/wakeup and not
> an ERROR, which should be fine at the end, just mentioning in
> passing.. Injpoint waits depend on atomics on HEAD, which is more
> portable, hence not an issue if one has the idea to do waits outside
> of a transaction.
> --

Thanks a lot, Michael, for taking care of this and for the explanation.

The original report in [1] also had this closely related problem.

> Note how it is currently not possible to safely add a UNIQUE
> DEFERRED constraint following the example in
> https://www.postgresql.org/docs/18/sql-altertable.html
>
> CREATE UNIQUE INDEX CONCURRENTLY dist_id_temp_idx ON distributors (dist_id);
> ALTER TABLE distributors DROP CONSTRAINT distributors_pkey,
> ADD CONSTRAINT distributors_pkey PRIMARY KEY USING INDEX
> dist_id_temp_idx;
>
> For this to work safely with UNIQUE DEFERRED constraints, I assume it would
> be necessary to add an option to CREATE INDEX to make an index DEFERRED.

So is that something worth looking into? I'm not sure if a deferred
index makes sense in general but is there something that can be done
for this specific scenario?

[1] https://www.postgresql.org/message-id/flat/cc0470801d4ee46bd85f94c2516fd31b%40nimrod.no

Regards,
Nitin Motiani
Google