From: Antonin Houska <ah@cybertec.at>
To: alvherre@kurilemu.de
cc: Noah Misch <noah@leadboat.com>, Andres Freund <andres@anarazel.de>,
    pgsql-hackers@lists.postgresql.org,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Race conditions in logical decoding
In-reply-to: <aqPBWUkBniZcxRl-@alvherre.pgsql>
References: <aqPBWUkBniZcxRl-@alvherre.pgsql>
Comments: In-reply-to =?us-ascii?Q?=3D=3Futf-8=3FQ=3F=3DC3=3D81lvaro=3F=3D?=
 Herrera <alvherre@kurilemu.de>
   message dated "Fri, 11 Sep 2026 11:03:14 +0200."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Sep 2026 11:43:15 +0200
Message-ID: <13367.1789119795@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/13367.1789119795%40localhost>
Precedence: bulk

=C3=81lvaro Herrera <alvherre@kurilemu.de> wrote:

> On 2026-Sep-10, Noah Misch wrote:
>=20
> > On Fri, Aug 21, 2026 at 08:16:02PM +0200, =C3=81lvaro Herrera wrote:
> > > So, what do you think of the attached?
> >=20
> > I see $SUBJECT lost open item status because released versions have the=
 same
> > defect.  However, REPACK (CONCURRENTLY) increases the importance of $SU=
BJECT
> > and other logical replication data loss causes.  In v18, one can recrea=
te the
> > replica or run integrity checks before a cutover.  REPACK (CONCURRENTLY)
> > automates the chain: one command starts replication, waits for consiste=
ncy,
> > and deletes the last known good copy.
> >=20
> > If v19 ships without a fix for $SUBJECT, I think REPACK (CONCURRENTLY) =
docs
> > need to warn about the situation.  How do you see it?
>=20
> 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.

Actually even the impact on logical replication is worse than described
above. As I pointed out at the beginning of this thread, even the data on t=
he
publisher can get corrupted: if visibility checks work incorrectly, hint bi=
ts
can be set incorrectly as well. The isolation tester spec file in [1] expla=
ins
the problem more in detail.

I'm not sure if such corruption was already reported - the race is probably
pretty rare - but it's possible. As for REPACK (CONCURRENTLY), I think it
makes the corruption more likely to happen because it's an additional use c=
ase
for the snapshot built by the logical decoding system.

[1] https://www.postgresql.org/message-id/flat/aqPBWUkBniZcxRl-%40alvherre.=
pgsql#828c33540c873236a693bfe84f6e8fac

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