Feedback-ID: ia2694551:Fastmail
Date: Tue, 19 May 2026 20:52:13 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>,
	Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
 Andres Freund <andres@anarazel.de>,
	Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
 Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Pg Hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Treat <rob@xzilla.net>
Subject: Re: Adding REPACK [concurrently]
Message-ID: <ageZ5buqLpgrXA5F@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAA4eK1+nJUc147td7NgVuW=gjV9+Rd04+kkLssQL5MR1oUMnJA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ageZ5buqLpgrXA5F%40alvherre.pgsql>
Precedence: bulk

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.
The revert should be a simple patch.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/