Horton

Re: Disabled logical replication origin session causes primary key errors

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, vignesh C <vignesh21@gmail.com>, Shawn McCoy <shawn.the.mccoy@gmail.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, "drewwcallahan@gmail.com" <drewwcallahan@gmail.com>, "scott@meads.us" <scott@meads.us>
Date: 2025-04-23T09:01:18Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix an oversight in 3f28b2fcac.

  2. Don't advance origin during apply failure.

On Wed, Apr 23, 2025 at 7:11 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > +# The bug was that the replication origin wasn’t updated whe
> > +# apply_error_callback() was called with elevel >= ERROR, and the apply
> > worker
> > +# continued running afterward.
> >
> > I think it would be better to mention the fact that the problem
> > happened when an error was caught for instance by a plpgsql function.
> > How about rewriting it as follows?
> >
> > # The bug was that when an ERROR was caught, for instance by a
> > PL/pgSQL function,
> > # the apply worker reset the replication origin but continued processing
> > # subsequent changes. This behavior resulted in a failure to update
> > the replication
> > # origin during further apply operations.
>
> I tried to describe the internal reasons of bugs, but yours did reported facts.
> +1, replaced.
>

Pushed the patch after slightly changing the comments.

-- 
With Regards,
Amit Kapila.