Re: Adding REPACK [concurrently]

Antonin Houska <ah@cybertec.at>

From: Antonin Houska <ah@cybertec.at>

To: Robert Treat <rob@xzilla.net>

Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Fujii Masao <masao.fujii@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-08-25T16:54:12Z

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

Robert Treat <rob@xzilla.net> wrote:

> On Mon, Aug 25, 2025 at 10:15 AM Mihail Nikalayeu
> <mihailnikalayeu@gmail.com> wrote:
> > 1) we have a whole initial table snapshot with all xmin copied from
> > the original table. All such xmin are committed.
> > 2) appling transaction sees ALL the self-alive (no xmax) tuple in it
> > because its xmin\xmax is committed and SnapshotSelf is happy with it
> > 3) each update/delete during the replay selects the last existing
> > tuple version, updates it xmax=original xid and inserts a new one
> > keeping with xmin=orignal xid
> > 4) --//--
> > 5) --//--
> >
> 
> Advancing the tables min xid to at least repack XID is a pretty big
> feature, but the above scenario sounds like it would result in any
> non-modified pre-existing tuples ending up with their original xmin
> rather than repack XID, which seems like it could lead to weird
> side-effects. Maybe I am mis-thinking it though?

What we discuss here is how to keep visibility information of tuples (xmin,
xmax, ...) unchanged. Both CLUSTER and VACUUM FULL already do that. However
it's not trivial to ensure that REPACK with the CONCURRENTLY option does as
well.

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