MIME-Version: 1.0
References: 
 <TY4PR01MB17718B44164522D0798F8E898940A2@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <ahW7vUWvDDJdE4zU@alvherre.pgsql>
 <TY4PR01MB177189B910069E99897E4323D94082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CAA4eK1Jpfe+nhV_KX0qKHTdLjwLEOPFVLrvCrXxLUxWptT6x5g@mail.gmail.com>
 <CAA4eK1LFqdh4=b4t3OTpmCMs211-9dJEG8JdcV1ikN94LBum9w@mail.gmail.com>
 <TY4PR01MB177181DF3B3DA853AA2298D8D94092@TY4PR01MB17718.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <TY4PR01MB177181DF3B3DA853AA2298D8D94092@TY4PR01MB17718.jpnprd01.prod.outlook.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 29 May 2026 08:39:18 -0700
Message-ID: 
 <CAA4eK1LtgqdC21EoES0WkiBvB5=k5pMxm5zZahS9f2mSszdLrA@mail.gmail.com>
Subject: Re: Adding REPACK [concurrently]
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Antonin Houska <ah@cybertec.at>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Treat <rob@xzilla.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1LtgqdC21EoES0WkiBvB5%3Dk5pMxm5zZahS9f2mSszdLrA%40mail.gmail.com>
Precedence: bulk

On Wed, May 27, 2026 at 10:18=E2=80=AFPM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thursday, May 28, 2026 11:34 AM Amit Kapila <amit.kapila16@gmail.com> =
wrote:
> > On Wed, May 27, 2026 at 5:31=E2=80=AFPM Amit Kapila <amit.kapila16@gmai=
l.com>
> > wrote:
> > >
> > > On Wed, May 27, 2026 at 1:08=E2=80=AFAM Zhijie Hou (Fujitsu)
> > > <houzj.fnst@fujitsu.com> wrote:
> > > >
> > > > 0001 remains unchanged.
> > > >
> > >
> > > Few minor comments:
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > Commit message says: "This change does not advance catalog_xmin.
> > REPACK already holds a snapshot that prevents catalog dead tuple remova=
l,
> > so catalog_xmin handling can be addressed independently.".
> > Isn't it equally important to advance this, otherwise, for long running=
 REPACKs
> > dead tuples will be accumulated needlessly? If so, do we have any ideas=
 to
> > avoid this?
>
> My understanding is that dead tuple accumulation is common to all long-ru=
nning
> commands (including CLUSTER, VACUUM FULL, and REPACK without CONCURRENTLY=
). As
> long as a command holds a snapshot for a long time while scanning and cop=
ying
> data, the backend xmin will cause similar accumulation. So, this doesn't =
seem
> like a new issue to me, and given that catalog_xmin only affect tuples in=
 system
> catalog which is less harmful, I thought it could be handled independentl=
y.
> There was a proposal to improve this case in [1].
>

Fair enough. It makes sense to deal with catalog_xmin separately.

> Attaching the v4 patch which improved the comments and commit message as
> suggested.
>

I haven't tested it but otherwise the code changes looks good to me.

--=20
With Regards,
Amit Kapila.