Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Mihail Nikalayeu <michail.nikolaev@gmail.com>

From: Michail Nikolaev <michail.nikolaev@gmail.com>

To: Matthias van de Meent <boekewurm+postgres@gmail.com>

Cc: Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>

Date: 2024-02-21T08:35:40Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Revert changes to CONCURRENTLY that "sped up" Xmin advance
- e28bb8851969 15.0 cited
VACUUM: ignore indexing operations with CONCURRENTLY
- d9d076222f5b 14.0 cited
Avoid spurious waits in concurrent indexing
- c98763bf51bf 14.0 cited

One more idea - is just forbid HOT prune while the second phase is
running. It is not possible anyway currently because of snapshot held.

Possible enhancements:
* we may apply restriction only to particular tables
* we may apply restrictions only to part of the tables (not yet
scanned by R/CICs).

Yes, it is not an elegant solution, limited, not reliable in terms of
architecture, but a simple one.