public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Antonin Houska <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Fri, 29 May 2026 08:39:18 -0700
Message-ID: <CAA4eK1LtgqdC21EoES0WkiBvB5=k5pMxm5zZahS9f2mSszdLrA@mail.gmail.com> (raw)
In-Reply-To: <TY4PR01MB177181DF3B3DA853AA2298D8D94092@TY4PR01MB17718.jpnprd01.prod.outlook.com>
References: <TY4PR01MB17718B44164522D0798F8E898940A2@TY4PR01MB17718.jpnprd01.prod.outlook.com>
<[email protected]>
<TY4PR01MB177189B910069E99897E4323D94082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
<CAA4eK1Jpfe+nhV_KX0qKHTdLjwLEOPFVLrvCrXxLUxWptT6x5g@mail.gmail.com>
<CAA4eK1LFqdh4=b4t3OTpmCMs211-9dJEG8JdcV1ikN94LBum9w@mail.gmail.com>
<TY4PR01MB177181DF3B3DA853AA2298D8D94092@TY4PR01MB17718.jpnprd01.prod.outlook.com>
On Wed, May 27, 2026 at 10:18 PM Zhijie Hou (Fujitsu)
<[email protected]> wrote:
>
> On Thursday, May 28, 2026 11:34 AM Amit Kapila <[email protected]> wrote:
> > On Wed, May 27, 2026 at 5:31 PM Amit Kapila <[email protected]>
> > wrote:
> > >
> > > On Wed, May 27, 2026 at 1:08 AM Zhijie Hou (Fujitsu)
> > > <[email protected]> wrote:
> > > >
> > > > 0001 remains unchanged.
> > > >
> > >
> > > Few minor comments:
> > > =================
> >
> > 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?
>
> My understanding is that dead tuple accumulation is common to all long-running
> commands (including CLUSTER, VACUUM FULL, and REPACK without CONCURRENTLY). As
> long as a command holds a snapshot for a long time while scanning and copying
> 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 independently.
> 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.
--
With Regards,
Amit Kapila.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <CAA4eK1LtgqdC21EoES0WkiBvB5=k5pMxm5zZahS9f2mSszdLrA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox