> > 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
