Date: Thu, 10 Sep 2026 16:49:11 -0700
From: Noah Misch <noah@leadboat.com>
To: =?iso-8859-1?Q?=C1lvaro?= Herrera <alvherre@kurilemu.de>
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: <20260910234911.58.noahmisch@microsoft.com>
References: <202603201543.t6gxppyyk66p@alvherre.pgsql>
 <aoiRAEAAzDnXfkDN@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <aoiRAEAAzDnXfkDN@alvherre.pgsql>
User-Agent: Mutt/2.3.0 (2026-01-25)
Archived-At: 
 <https://www.postgresql.org/message-id/20260910234911.58.noahmisch%40microsoft.com>
Precedence: bulk

On Mon, Jan 19, 2026 at 05:29:25PM +0100, Antonin Houska wrote:
> A stress test [1] for the REPACK patch [1] revealed data
> corruption. Eventually I found out that the problem is in postgres core. In
> particular, it can happen that a COMMIT record is decoded, but before the
> commit could be recorded in CLOG, a snapshot that takes the commit into
> account is created and even used. Visibility checks then work incorrectly
> until the CLOG gets updated.

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?