Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CAJSLCQ36BynNAC2vYuWkJ-Y-rECRFoE4rB7NV-O+ENE3bKdp4A@mail.gmail.com
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Mihail Nikalayeu <mihailnikalayeu@gmail.com>)
Responses Re: Adding REPACK [concurrently]
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUG] Remove self joins causes 'variable not found in subplan target lists' error
Next
From: Nathan Bossart
Date:
Subject: Re: GetNamedLWLockTranche crashes on Windows in normal backend