Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Mikhail Nikalayeu <mihailnikalayeu@gmail.com>

From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>

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

Cc: Sergey Sargsyan <sergey.sargsyan.2001@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrey Borodin <amborodin86@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>

Date: 2025-11-27T18:59:55Z

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

Hello, Mathias!

On Thu, Nov 27, 2025 at 7:41 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> I'm not sure a complete and common approach is that easy between CIC
> and REPACK CONCURRENTLY.

Yes, you're right, but I hope something like [0] may work.

[0]: https://www.postgresql.org/message-id/CADzfLwXN4NXv8C%2B8GzbMJvRaBkJMs838c92CM-6Js-%3DWpi5aRQ%40mail.gmail.com