diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2022-05-31 21:24:59 +0200 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2022-05-31 21:24:59 +0200 |
| commit | 042b584c7f7d6216c54359c0ee0f613ba3b3d9c2 (patch) | |
| tree | 0d214b09f32d0c23263b3f18f274d2c554ad5643 /doc/src | |
| parent | c47a558528dd79fe76c698cde7e23f38610b05ed (diff) | |
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.slavov@gmail.com>
Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru>
Diagnosys-by: Michael Paquier <michael@paquier.xyz>
Diagnosys-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/ref/create_index.sgml | 2 | ||||
| -rw-r--r-- | doc/src/sgml/ref/reindex.sgml | 2 |
2 files changed, 0 insertions, 4 deletions
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 11179f0b9d9..df45bc97466 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -845,8 +845,6 @@ Indexes: Like any long-running transaction, <command>CREATE INDEX</command> on a table can affect which tuples can be removed by concurrent <command>VACUUM</command> on any other table. - Excepted from this are operations with the <literal>CONCURRENTLY</literal> - option for indexes that are not partial and do not index any expressions. </para> <para> diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index e6b25ee670f..22dbb520d52 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -470,8 +470,6 @@ Indexes: Like any long-running transaction, <command>REINDEX</command> on a table can affect which tuples can be removed by concurrent <command>VACUUM</command> on any other table. - Excepted from this are operations with the <literal>CONCURRENTLY</literal> - option for indexes that are not partial and do not index any expressions. </para> <para> |