| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Zhijie Hou <houzhijie22(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add a hook for handling logical decoding messages on subscribers. |
| Date: | 2026-11-02 12:47:46 |
| Message-ID: | CAA4eK1J1Jdz6DunCPWJ2KCpGbSERxgv+xydXkTa+19GgG5dPOA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 31, 2026 at 6:05 PM Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
>
> On Sat, Oct 31, 2026 at 06:34 AM Masahiko Sawada wrote:
> >
> > It seems to me worth adding a check for tablesync workers since both
> > the apply workers and the tablesync workers call
> > walrcv_startstreaming() and it would prevent mistakes by future
> > changes.
> >
> > I've attached the updated patch.
>
> While reviewing how transactional logical messages interact with
> subtransaction aborts, I noticed an issue with streamed transactions. In
> non-streaming mode, it works as expected (i.e., the message is not
> applied if the subtransaction is aborted). However, in streaming mode,
> if a transactional message is emitted in a subtransaction that is later
> aborted, the STREAM ABORT message does not discard or roll back that
> logical message, so it still gets applied in both streaming=on and
> streaming=parallel modes.
>
> I think the reason is that ReorderBufferApplyMessage() passes the
> top-level txn rather than change->txn to rb->stream_message(), so
> logical decoding always sends the top-level XID instead of the
> subtransaction XID when outputting a streamed message. Thus the apply
> worker cannot associate the message with the subtransaction and cannot
> roll it back properly.
>
> Strictly speaking, this is an existing issue, but it becomes more
> visible once subscribers can handle logical messages via this hook. So
> it may be worth considering whether to fix it along with this patch or
> separately.
>
Right, it didn't have any impact till now for native replication as we
were just ignoring these messages on subscribers. I think this could
have impacted output-plugins if they used this functionality. I think
we can fix this separately but it is better to fix it before this
patch as this patch can expose a hidden issue.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2026-11-02 12:49:55 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Lucas Jeffrey | 2026-11-02 12:38:58 | Re: Re: [PATCH] Fix segmentation fault caused by reentrancy in RI_Fkey_cascade_del (ri_triggers.c) |