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

From Amit Kapila
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CAA4eK1K7Q=CNNr0_t5aXVD8t9UW2xSFdjOgG4cSB6-G2c8DK=Q@mail.gmail.com
Whole thread
In response to Re: Adding REPACK [concurrently]  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
On Tue, May 19, 2026 at 11:52 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2026-May-14, Amit Kapila wrote:
>
> > The broader issue is that the entire logical decoding mechanism is
> > designed to process cluster-wide transactions. This patch tries to
> > bypass that foundational assumption, but only during the initial
> > snapshot construction while processing running_xacts record.
> >
> > To be clear, I am not against the idea of db-specific snapshots to
> > enable concurrent repacks. My concern is simply the time required to
> > get the architecture right. In its current state, we need more time to
> > carefully consider how this db-specific concept interacts with the
> > rest of the logical decoding machinery, which is built for
> > cluster-wide records.
>
> Hmm.  So at this point I have to admit that the time I'll have before
> beta 1 is going to be very scarce.  You're probably right that it's
> better to revert db-specific snapshots in pg19, and try again for 20.
>

Sounds reasonable.

> The revert should be a simple patch.
>

I also think so.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Daniil Davydov
Date:
Subject: ERROR during COMMIT PREPARED can leave orphaned locks
Next
From: "Jonathan Gonzalez V."
Date:
Subject: Re: splitting pg_resetwal output strings