| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Antonin Houska <ah(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
| Subject: | Re: Race conditions in logical decoding |
| Date: | 2026-09-11 09:03:14 |
| Message-ID: | aqPBWUkBniZcxRl-@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rahila Syed | 2026-09-11 09:05:34 | Re: Fix unsafe coding in ResourceOwnerReleaseAll() |
| Previous Message | Amit Langote | 2026-09-11 08:52:27 | Re: Revert RI fast-path batching from REL_19_STABLE |