Horton

Re: Disabled logical replication origin session causes primary key errors

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.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-23T15:58:27Z
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 2:01 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

Thank you!

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com