Re: Race conditions in logical decoding

Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> 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.

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 the
publisher can get corrupted: if visibility checks work incorrectly, hint bits
can be set incorrectly as well. The isolation tester spec file in [1] explains
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 case
for the snapshot built by the logical decoding system.

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

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