On Sat, Oct 31, 2026 at 6:05 PM Zhijie Hou <[email protected]> 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.
