⇑ Upgrade to 14.1 released on 2021-11-11 - docs
Avoid assertion failure when inserting NaN into a BRIN float8 or float4 minmax_multi_ops index (Tomas Vondra)
In production builds, such cases would result in a somewhat inefficient, but not actually incorrect, index.
Make contrib/amcheck skip unlogged tables when running on a standby server (Mark Dilger)
It's appropriate to do this since such tables will be empty, and unlogged indexes were already handled similarly.
Add more defensive checks around B-tree posting list splits (Peter Geoghegan)
This change should help detect index corruption involving duplicate table TIDs.
Fix CREATE INDEX CONCURRENTLY to wait for the latest prepared transactions (Andrey Borodin)
Rows inserted by just-prepared transactions might be omitted from the new index, causing queries relying on the index to miss such rows. The previous fix for this type of problem failed to account for PREPARE TRANSACTION commands that were still in progress when CREATE INDEX CONCURRENTLY checked for them. As before, in installations that have enabled prepared transactions (max_prepared_transactions > 0), it's recommended to reindex any concurrently-built indexes in case this problem occurred when they were built.
Disallow ALTER INDEX index ALTER COLUMN col SET (options) (Nathan Bossart, Michael Paquier)
While the parser accepted this, it's undocumented and doesn't actually work.
Ensure that parallel VACUUM doesn't miss any indexes (Peter Geoghegan, Masahiko Sawada)
A parallel VACUUM would fail to process indexes that are below the min_parallel_index_scan_size cutoff, if the table also has at least two indexes that are above that size. This could result in those indexes becoming corrupt, since they'd still contain references to any heap entries removed by the VACUUM; subsequent queries using such indexes would be likely to return rows they shouldn't. This problem does not affect autovacuum, since it doesn't use parallel vacuuming. However, it is advisable to reindex any manually-vacuumed tables that have the right mix of index sizes.
Fix REINDEX CONCURRENTLY to preserve operator class parameters that were attached to the target index (Michael Paquier)
Avoid race condition that can cause backends to fail to add entries for new rows to an index being built concurrently (Noah Misch, Andrey Borodin)
While it's apparently rare in the field, this case could potentially affect any index built or reindexed with the CONCURRENTLY option. It is recommended to reindex any such indexes to make sure they are correct.
Ensure that the correct lock level is used when renaming a table (Nathan Bossart, Álvaro Herrera)
For historical reasons, ALTER INDEX ... RENAME can be applied to any sort of relation. The lock level required to rename an index is lower than that required to rename a table or other kind of relation, but the code got this wrong and would use the weaker lock level whenever the command is spelled ALTER INDEX.
Prevent pg_amcheck from checking temporary relations, as well as indexes that are invalid or not ready (Mark Dilger)
This avoids unhelpful checks of relations that will almost certainly appear inconsistent.
Avoid O(N^2) behavior in some list-manipulation operations (Nathan Bossart, Tom Lane)
These changes fix slow processing in several scenarios, including: when a standby replays a transaction that held many exclusive locks on the primary; when many files are due to be unlinked after a checkpoint; when hash aggregation involves many batches; and when pg_trgm extracts indexable conditions from a complex regular expression. Only the first of these scenarios has actually been reported from the field, but they all seem like plausible consequences of inefficient list deletions.