Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 11 Sep 2026 11:03:14 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Noah Misch <noah@leadboat.com>
Cc: Andres Freund <andres@anarazel.de>, Antonin Houska <ah@cybertec.at>,
	pgsql-hackers@lists.postgresql.org,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Race conditions in logical decoding
Message-ID: <aqPBWUkBniZcxRl-@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20260910234911.58.noahmisch@microsoft.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aqPBWUkBniZcxRl-%40alvherre.pgsql>
Precedence: bulk

On 2026-Sep-10, Noah Misch wrote:

> On Fri, Aug 21, 2026 at 08:16:02PM +0200, Álvaro Herrera wrote:
> > So, what do you think of the attached?
> 
> I see $SUBJECT lost open item status because released versions have the same
> defect.  However, REPACK (CONCURRENTLY) increases the importance of $SUBJECT
> and other logical replication data loss causes.  In v18, one can recreate the
> replica or run integrity checks before a cutover.  REPACK (CONCURRENTLY)
> automates the chain: one command starts replication, waits for consistency,
> and deletes the last known good copy.
> 
> If v19 ships without a fix for $SUBJECT, I think REPACK (CONCURRENTLY) docs
> need to warn about the situation.  How do you see it?

I think this kind of bug makes logical decoding effectively unusable,
because you can never predict when this bug is going to hit and
therefore when you're going to silently lose data.  I agree that REPACK
(CONCURRENTLY) having automated the potential for data loss is severe.
I doubt it'd make sense to release it with this bug.  So my intention is
to get it fixed before release.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/