Re: Adding REPACK [concurrently]

Mikhail Nikalayeu <mihailnikalayeu@gmail.com>

From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>

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

Cc: Fujii Masao <masao.fujii@gmail.com>, Robert Treat <rob@xzilla.net>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Antonin Houska <ah@cybertec.at>

Date: 2025-08-20T23:44:00Z

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-0006-Preserve-visibility-information-of-the-concurren.patch (application/octet-stream) patch v18-0006

Hello everyone!

Alvaro Herrera <alvherre@alvh.no-ip.org>:
> Please note that Antonin already implemented this.  See his patches
> here:
> https://www.postgresql.org/message-id/77690.1725610115%40antos
> I proposed to leave this part out initially, which is why it hasn't been
> reposted.  We can review and discuss after the initial patches are in.

I think it is worth pushing it at least in the same release cycle.

> But you're welcome to review that part specifically if you're so
> inclined, and offer feedback on it.  (I suggest to rewind back your
> checked-out tree to branch master at the time that patch was posted, for
> easy application.  We can deal with a rebase later.)

I have rebased that on top of v18 (attached).

Also, I think I found an issue (or lost something during rebase): we
must preserve xmin,cmin during initial copy
to make sure that data is going to be visible by snapshots of
concurrent changes later:

static void
reform_and_rewrite_tuple(......)
.....
      /*It is also crucial to stamp the new record with the exact same
xid and cid,
      * because the tuple must be visible to the snapshot of the
applied concurrent
      * change later.
      */
      CommandId      cid = HeapTupleHeaderGetRawCommandId(tuple->t_data);
      TransactionId   xid = HeapTupleHeaderGetXmin(tuple->t_data);

      heap_insert(NewHeap, copiedTuple, xid, cid, HEAP_INSERT_NO_LOGICAL, NULL);

I'll try to polish that part a little bit.

> Because having an MVCC-safe mode has drawbacks, IMO we should make it
> optional.
Do you mean some option for the command? Like REPACK (CONCURRENTLY, SAFE)?

Best regards,
Mikhail.