Álvaro Herrera <[email protected]> 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
