Re: Adding REPACK [concurrently]

Antonin Houska <ah@cybertec.at>

From: Antonin Houska <ah@cybertec.at>

To: Alvaro Herrera <alvherre@alvh.no-ip.org>

Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, Robert Treat <rob@xzilla.net>, Pg Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-08-15T12:32:09Z

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 →

Improve REPACK (CONCURRENTLY) error messages some more
- 378dffaf8c80 19 (unreleased) landed
Add CONCURRENTLY option to REPACK
- 28d534e2ae0a 19 (unreleased) landed
Make index_concurrently_create_copy more general
- 33bf7318f94c 19 (unreleased) landed
Document the 'command' column of pg_stat_progress_repack
- a630ac5c2016 19 (unreleased) landed
Introduce the REPACK command
- ac58465e0618 19 (unreleased) landed
Split vacuumdb to create vacuuming.c/h
- c4067383cb2c 19 (unreleased) landed
Revert changes to CONCURRENTLY that "sped up" Xmin advance
- 042b584c7f7d 14.4 cited

Attachments

v18-0001-Add-REPACK-command.patch (text/x-diff)

Antonin Houska <ah@cybertec.at> wrote:

> Mihail Nikalayeu <mihailnikalayeu@gmail.com> wrote:
> 
> > One more thing - I think build_new_indexes and
> > index_concurrently_create_copy are very close in semantics, so it
> > might be a good idea to refactor them a bit.
> 
> You're right. I think I even used the latter for reference when writing the
> first.
> 
> 0002 in the attached series tries to fix that. build_new_indexes() (in 0004)
> is simpler now.

This is v18 again. Parts 0001 through 0004 are unchanged, however 0005 is
added. It implements a new client application pg_repackdb. (If I posted 0005
alone its regression tests would not work. I wonder if the cfbot handles the
repeated occurence of the 'v18-' prefix correctly.)

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com