Horton

Re: Adding REPACK [concurrently]

Robert Treat <rob@xzilla.net>

View thread
From: Robert Treat <rob@xzilla.net>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Fujii Masao <masao.fujii@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-25T16:36:10Z
Lists: pgsql-hackers 
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?

Robert Treat
https://xzilla.net