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>
In-Reply-To: 
 <CAA4eK1Jpfe+nhV_KX0qKHTdLjwLEOPFVLrvCrXxLUxWptT6x5g@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Wed, 27 May 2026 20:34:08 -0700
Message-ID: 
 <CAA4eK1LFqdh4=b4t3OTpmCMs211-9dJEG8JdcV1ikN94LBum9w@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/CAA4eK1LFqdh4%3Db4t3OTpmCMs211-9dJEG8JdcV1ikN94LBum9w%40mail.gmail.com>
Precedence: bulk

On Wed, May 27, 2026 at 5:31=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.co=
m> 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
removal, 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?

--=20
With Regards,
Amit Kapila.