postgresql.git/src/backend/commands/indexcmds.c, branch REL_19_STABLE

Fix RI fast-path race with REINDEX CONCURRENTLY

2026-08-18T08:07:02Z

The RI fast path reads pg_constraint.conindid before taking RowShareLock on the referenced table. REINDEX CONCURRENTLY can repoint the constraint and mark the old index dead, or drop it, between those operations. A backend in that window does not yet hold a relation lock, so it is not covered by REINDEX CONCURRENTLY's waits for lockers. Opening an index that has already been dropped produces "could not open relation with OID". Opening one that has only been marked dead can produce wrong answers: the index is no longer maintained or vacuumed, so a scan can miss a referenced row or follow a stale entry to a reused heap line pointer. After locking the referenced table, reload the constraint and use its current conindid. LockRelationOid() processes invalidation messages after acquiring the lock, so the reload sees a committed index swap. If the lock was already held, REINDEX CONCURRENTLY cannot mark the old index dead or drop it until the transaction releases that lock, so continuing to use the old conindid is safe. Do this at both RI fast-path call sites. Add injection-point coverage for old indexes that have either been dropped or marked dead. Author: Mihail Nikalayeu Discussion: https://postgr.es/m/CADzfLwUJiVuv69uwuF5z4TrMhNkVwQUXW03q+uVNwmYFLtjEhw@mail.gmail.com Backpatch-through: 19

Check for USAGE privilege on types used by stored expressions.

2026-08-10T13:38:06Z

This omission allowed roles without USAGE on a type to create stored expressions that depend on it, which could prevent the owner from changing the type later. The checks deliberately live in the command paths rather than the dependency-recording routines. Those routines also run whenever the server re-derives an existing expression, and re-checking there would break routine maintenance for an owner who has since lost USAGE on a type its objects already reference. (Checking in the dependency-recording routines would also require additional CommandCounterIncrement() calls to avoid spurious errors.) The addition of a parameter to AlterDomainAddConstraint() breaks ABI compatibility, but we are unaware of any impacted third-party code. Reported-by: Noah Misch Author: Nathan Bossart Reviewed-by: Noah Misch Reviewed-by: Tom Lane Reviewed-by: Robert Haas Security: CVE-2026-6470 Backpatch-through: 14

Fix propagation of indimmediate flag in index_create_copy()

2026-07-27T23:35:09Z

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 Discussion: https://postgr.es/m/CAH5HC97JmjPpgiQOqW9xm8qXhNiu7zZ1Qh+FfhEESJuDv69kuQ@mail.gmail.com Backpatch-through: 14

Allow index_create to suppress index_build progress reporting

2026-04-05T11:34:08Z

A future REPACK patch wants a way to suppress index_build doing its progress reports when building an index, because that would interfere with repack's own reporting; so add an INDEX_CREATE_SUPPRESS_PROGRESS bit that enables this. Furthermore, change the index_create_copy() API so that it takes flag bits for index_create() and passes them unchanged. This gives its callers more direct control, which eases the interface -- now its callers can pass the INDEX_CREATE_SUPPRESS_PROGRESS bit directly. We use it for the current caller in REINDEX CONCURRENTLY, since it's also not interested in progress reporting, since it doesn't want index_build() to be called at all in the first place. One thing to keep in mind, pointed out by Mihail, is that we're not suppressing the index-AM-specific progress report updates which happen during ambuild(). At present this is not a problem, because the values updated by those don't overlap with those used by commands other than CREATE INDEX; but maybe in the future we'll want the ability to suppress them also. (Alternatively we might want to display how each index-build-subcommand progresses during REPACK and others.) Author: Antonin Houska Author: Álvaro Herrera Reviewed-by: Mihail Nikalayeu Discussion: https://postgr.es/m/102906.1773668762@localhost

Make index_concurrently_create_copy more general

2026-04-04T18:38:26Z

Also rename it to index_create_copy. Add a 'boolean concurrent' option, and make it work for both cases: in concurrent mode, just create the catalog entries; caller is responsible for the actual building later. In non-concurrent mode, the index is built right away. This allows it to be reused for other purposes -- specifically, for concurrent REPACK. (With the CONCURRENTLY option, REPACK cannot simply swap the heap file and rebuild its indexes. Instead, it needs to build a separate set of indexes, including their system catalog entries, *before* the actual swap, to reduce the time AccessExclusiveLock needs to be held for. This approach is different from what CREATE INDEX CONCURRENTLY does.) Per a suggestion from Mihail Nikalayeu. Author: Antonin Houska Reviewed-by: Mihail Nikalayeu Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/41104.1754922120@localhost

Remove bits* typedefs.

2026-03-30T21:12:08Z

In addition to removing the bits8, bits16, and bits32 typedefs, this commit replaces all uses with uint8, uint16, or uint32. bits* provided little benefit beyond establishing the intent of the variable, and they were inconsistently used for that purpose. Third-party code should instead use the corresponding uint* typedef. Suggested-by: Andres Freund Reviewed-by: Álvaro Herrera Reviewed-by: Tom Lane Reviewed-by: Robert Haas Reviewed-by: Michael Paquier Reviewed-by: Peter Eisentraut Reviewed-by: Melanie Plageman Reviewed-by: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/absbX33E4eaA0Ity%40nathan

Prevent spurious "indexes on virtual generated columns are not supported".

2026-03-24T10:28:33Z

Both of the checks in DefineIndex() that can produce this error message have a guard against negative attribute numbers, but lack a guard to ensure that attno is non-zero. As a result, we can index off the beginning of the TupleDesc and read a garbage byte for attgenerated. If that byte happens to be 'v', we'll incorrectly produce the error mentioned above. The first call site is easy to hit: any attempt to create an expression index does so. The second one is not currently hit in the regression tests, but can be hit by something like CREATE INDEX ON some_table ((some_function(some_table))). Found by study of a test_plan_advice failure on buildfarm member skink, though this issue has nothing to do with test_plan_advice and seems to have only been revealed by happenstance. Backpatch-through: 18 Reviewed-by: Tom Lane Discussion: http://postgr.es/m/CA+TgmoacixUZVvi00hOjk_d9B4iYKswWP1gNqQ8Vfray-AcOCA@mail.gmail.com

Add some const qualifiers enabled by typeof_unqual change on copyObject

2026-03-19T05:35:54Z

The recent commit to change copyObject() to use typeof_unqual allows cleaning up some APIs to take advantage of this improved qualifier handling. EventTriggerCollectSimpleCommand() is a good example: It takes a node tree and makes a copy that it keeps around for its internal purposes, but it can't communicate via its function signature that it promises not scribble on the passed node tree. That is now fixed. Reviewed-by: David Geier Discussion: https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org

Reduce header inclusions via execnodes.h

2026-03-16T13:34:57Z

Remove a bunch of #include lines from execnodes.h. Most of these requier suitable typedefs to be added, so that it still compiles standalone. In one case, the fix is to move a struct definition to the one .c file where it is needed. Also some light clean up in plannodes.h and genam.h, though not as extensive as in execnodes.h. Author: Álvaro Herrera Author: Andres Freund Discussion: https://postgr.es/m/202603131240.ihwqdxnj7w2o@alvherre.pgsql

Improve "constraint must include all partitioning columns" message.

2026-01-09T17:59:35Z

This formerly said "unique constraint must ...", which was accurate enough when it only applied to UNIQUE and PRIMARY KEY constraints. However, now we use it for exclusion constraints too, and in that case it's a tad confusing. Do what we already did in the errdetail message: print the constraint_type, so that it looks like "UNIQUE constraint ...", "EXCLUDE constraint ...", etc. Author: jian he Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CACJufxH6VhAf65Vghg4T2q315gY=Rt4BUfMyunkfRj0n2S9n-g@mail.gmail.com