Revert changes to CONCURRENTLY that "sped up" Xmin advance This reverts commit d9d076222f5b "VACUUM: ignore indexing operations with CONCURRENTLY".
These changes caused indexes created with the CONCURRENTLY option to miss heap tuples that were HOT-updated and HOT-pruned during the index creation. Before these changes, HOT pruning would have been prevented by the Xmin of the transaction creating the index, but because this change was precisely to allow the Xmin to move forward ignoring that backend, now other backends scanning the table can prune them. This is not a problem for VACUUM (which requires a lock that conflicts with a CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely occur. In other words, Xmin advancement was sped up, but at the cost of corrupting the resulting index. Regrettably, this means that the new feature in PG14 that RIC/CIC on very large tables no longer force VACUUM to retain very old tuples goes away. We might try to implement it again in a later release, but for now the risk of indexes missing tuples is too high and there's no easy fix. Backpatch to 14, where this change appeared. Reported-by: Peter Slavov <pet.sla...@gmail.com> Diagnosys-by: Andrey Borodin <x4...@yandex-team.ru> Diagnosys-by: Michael Paquier <mich...@paquier.xyz> Diagnosys-by: Andres Freund <and...@anarazel.de> Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/042b584c7f7d6216c54359c0ee0f613ba3b3d9c2 Modified Files -------------- doc/src/sgml/ref/create_index.sgml | 2 -- doc/src/sgml/ref/reindex.sgml | 2 -- src/backend/storage/ipc/procarray.c | 40 +++++++------------------------------ 3 files changed, 7 insertions(+), 37 deletions(-)