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: Shawn McCoy <shawn.the.mccoy@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, drewwcallahan@gmail.com, "scott@meads.us" <scott@meads.us>, Amit Kapila <amit.kapila16@gmail.com>
Date: 2025-04-20T05:53:26Z
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.

Hi,

Thank you for the report and sharing the reproducers.

On Fri, Apr 18, 2025 at 2:22 PM Shawn McCoy <shawn.the.mccoy@gmail.com> wrote:
>
> Hello,
>
> We have discovered a recent regression in the Origin handling of logical replication apply workers. We have found the cause of the issue was due to the worker resetting its local origin session information during the processing of an error that is
> silently handled allowing the worker to continue. We suspect this is caused by the recent change made in the following thread, https://www.postgresql.org/message-id/TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com.
>
> The logical replication apply worker will originally setup the origin correctly. However, on the first insert will call into the trigger which will raise an exception. This exception will execute the error callback that resets the origin session state. The exception will then be silently handled, returning execution back to the apply worker.  In the second reproduction, a function based index is used with the same result.
>
> At this point, the apply worker can continue to commit these changes, but has cleared all local origin session state. As a result, we will not update our remote to local LSN mapping of the origin. Allowing for duplicate data to be applied.

I agree with your analysis. When the subscriber restarts the logical
replication, changes that happened since the last acknowledged LSN
would be replicated again.

With commit 3f28b2fcac33f, we reset the replication origin in
apply_error_callback() but I guess moving it to the PG_CATCH() block
in start_apply() might work.

Regards,

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