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: PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>

Date: 2023-12-20T16:53:27Z

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

> Yes, good catch.
> Assuming we have somehow prevented vac_truncate_clog from occurring
> during CIC, we can leave frozen and potentially frozen
> (xmin<frozenXID) for the second phase.

Just realized that we can leave this for the first stage to improve efficiency.
Since the ID is locked, anything that can be frozen will be visible in
the first stage.