agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: alvherre@kurilemu.de
Cc: Noah Misch <noah@leadboat.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Race conditions in logical decoding
Date: Fri, 11 Sep 2026 11:43:15 +0200
Message-ID: <13367.1789119795@localhost> (raw)
In-Reply-To: <aqPBWUkBniZcxRl-@alvherre.pgsql>
References: <aqPBWUkBniZcxRl-@alvherre.pgsql>
Álvaro Herrera <alvherre@kurilemu.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#828c33540c873236a693bfe...
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (38+ messages) latest in thread
Message-ID: <13367.1789119795@localhost>
Permalink: ../13367.1789119795@localhost/
Also on: postgresql.org/message-id/13367.1789119795@localhost
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, alvherre@kurilemu.de, noah@leadboat.com, andres@anarazel.de, mihailnikalayeu@gmail.com
Subject: Re: Race conditions in logical decoding
In-Reply-To: <13367.1789119795@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox