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?
