Re: Adding REPACK [concurrently]

From: Antonin Houska <ah(at)cybertec(dot)at>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-04-01 12:31:21
Message-ID: 193349.1775046681@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Wed, Apr 1, 2026 at 3:13 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> >

> > Nevertheless, I'm not sure it's a good idea for snapbuild.c to handle special
> > cases like REPACK. Instead, I'm thinking if snapbuild.c can safely ignore XIDs
> > of backends connected to databases other than the one we're decoding.
> >
>
> What if such transactions have made changes in the global catalog?
> Even if that won't matter, I feel such a change would be quite
> fundamental to snapbuild machinery and changing at this point would be
> risky.

I had thought that catalog is usually needed only to retrieve the tuple
descriptor, but regression tests with some Assert() statements prove now that
shared catalogs can be accessed too. So that idea does not seem to be useful.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-04-01 12:35:01 Re: Adding REPACK [concurrently]
Previous Message Amit Kapila 2026-04-01 12:21:40 Re: Adding REPACK [concurrently]