agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix propagation of indimmediate flag in index_create_copy() 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/74276e685dd01a8834f05f7d8b29a140a264e127 Modified Files -------------- src/backend/catalog/index.c | 16 ++++++- src/backend/commands/indexcmds.c | 2 + src/include/catalog/index.h | 1 + src/test/modules/injection_points/Makefile | 1 + .../expected/reindex_concurrently_deferred.out | 41 ++++++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../specs/reindex_concurrently_deferred.spec | 50 ++++++++++++++++++++++ 7 files changed, 110 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9f6fb1191915f1baeb32ab11392af436cf869ce4 Modified Files -------------- src/backend/catalog/index.c | 16 ++++++- src/backend/commands/indexcmds.c | 2 + src/include/catalog/index.h | 1 + src/test/modules/injection_points/Makefile | 1 + .../expected/reindex_concurrently_deferred.out | 41 ++++++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../specs/reindex_concurrently_deferred.spec | 50 ++++++++++++++++++++++ 7 files changed, 110 insertions(+), 2 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e4527519b77e0f158e452fcbbcb2ac902d01ad44 Modified Files -------------- src/backend/catalog/index.c | 20 +++++++-- src/backend/commands/indexcmds.c | 2 + src/include/catalog/index.h | 1 + src/test/modules/injection_points/Makefile | 1 + .../expected/reindex_concurrently_deferred.out | 41 ++++++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../specs/reindex_concurrently_deferred.spec | 50 ++++++++++++++++++++++ 7 files changed, 113 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/28269fed661afce4ba9a9fd0bf6ce8c2f778f12f Modified Files -------------- src/backend/catalog/index.c | 20 +++++++-- src/backend/commands/indexcmds.c | 2 + src/include/catalog/index.h | 1 + src/test/modules/injection_points/Makefile | 1 + .../expected/reindex_concurrently_deferred.out | 41 ++++++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../specs/reindex_concurrently_deferred.spec | 50 ++++++++++++++++++++++ 7 files changed, 113 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ac222bea5b46b0498a0807edba2d780e42f80ea1 Modified Files -------------- src/backend/catalog/index.c | 20 +++++++++++++++++--- src/include/catalog/index.h | 1 + 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5b3712e31565ab9be18b7f8e36cee61ba6fc951e Modified Files -------------- src/backend/catalog/index.c | 20 +++++++++++++++++--- src/include/catalog/index.h | 1 + 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix propagation of indimmediate flag in index_create_copy() @ 2026-07-27 23:54 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2026-07-27 23:54 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix propagation of indimmediate flag in index_create_copy() index_create_copy is used to create copy definitions of existing indexes. Currently, it passes 0 as constr_flags to index_create(), which results in the copied index to always be created as immediate (indimmediate set to true). For deferrable unique constraints, it means that the transient index used during the phase 2 of REINDEX CONCURRENTLY forces immediate constraint checks on concurrent inserts, which can cause unexpected constraint violations based on the definition of the parent table, inconsistently set in the copied index. To fix this without violating the contract of constr_flags (which should only be used when creating constraints) and without relaxing the strict assertion in index_create(), this introduces a new index creation flag: INDEX_CREATE_DEFERRABLE. If set, a copied index's indimmediate is set to false, meaning that unique constraints are not enforced immediately on insertion, but at transaction commit time. An isolation test for REINDEX CONCURRENTLY is added, based on an injection point waiting after phase 1 of the operation, where an index copy has been built and is able to accept DMLs for its validation in phase 2. The test is tentatively backpatched down to v17. INJECTION_POINT() is outside a transaction context, which should be fine on HEAD since 8daeaa9b642c but I suspect may cause issues in v19 and older branches due to the wait facility depending on condition variables and a DSM setup, but let's see what the buildfarm tells. Author: Nitin Motiani <nitinmotiani@google.com> Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/55adef7abbe8ecfa329335640b598cbb57be0f93 Modified Files -------------- src/backend/catalog/index.c | 20 +++++++++++++++++--- src/include/catalog/index.h | 1 + 2 files changed, 18 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-27 23:54 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz> 2026-07-27 23:54 pgsql: Fix propagation of indimmediate flag in index_create_copy() Michael Paquier <michael@paquier.xyz>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox