RE: Parallel Apply

On Thursday, April 23, 2026 6:05 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> >
> > I think the first thing we need to decide is the message format sent
> > to the parallel worker versus the format used for spooled messages.
> >
> > Option 1 (Current approach):
> > Message to parallel worker:
> > PARALLEL_APPLY_INTERNAL_MESSAGE (1 byte) +
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE (1 byte) +
> > WorkerInternalMsgType + data
> > Spooled message:
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE (1 byte) +
> > WorkerInternalMsgType + data
> >
> > Option 2 (Alternative):
> > Message to parallel worker:
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE (1 byte) +
> > WorkerInternalMsgType + data
> > Spooled message:
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE (1 byte) +
> > WorkerInternalMsgType + data
> >
> > Option 3 (Alternative):
> > Message to parallel worker:
> > PARALLEL_APPLY_INTERNAL_MESSAGE (1 byte) +
> > WorkerInternalMsgType + data
> > Spooled message:
> > WorkerInternalMsgType + data
> >
> > In Option 1, the extra PARALLEL_APPLY_INTERNAL_MESSAGE byte allows
> the
> > parallel worker to distinguish internal messages from logical
> > replication messages (which begin with PqReplMsg_WALData). Here,
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE serves purely as an apply action.
> >
> > Option 2 also works. The only minor issue is that
> > LOGICAL_REP_MSG_INTERNAL_MESSAGE serves two purposes: (1)
> > distinguishing from PqReplMsg_WALData in the parallel worker, and (2)
> > acting as an apply action in apply_spooled_messages(). I don't think this is a
> big issue, so I'm not strongly opposed to it.
> >
> > Option 3 is what the V12 patch implements. It is the simplest
> > approach, although it requires adding WorkerInternalMsgType values
> > directly into LogicalRepMsgType, which has been commented previously.
> >
>
> I did not find this in v12. v12 has WorkerInternalMsgType maintained
> separately. Did you mean v11?

Sorry for the typo, I meant V11.

>
> > ----
> >
> > The second question is how to implement it.
> >
> > - Option 1: Used in the latest patch (we can improve it to use distinct byte
> values for
> > PARALLEL_APPLY_INTERNAL_MESSAGE and
> LOGICAL_REP_MSG_INTERNAL_MESSAGE for clarity).
> >
> > - Option 2
> >
> > If we want to reuse LOGICAL_REP_MSG_INTERNAL_MESSAGE for both
> > purposes, we could directly call apply_handle_internal_message in the
> > parallel worker like this (We might need to set
> > apply_error_callback_arg.command for this calling manually, so that the
> errcontext can work):
> >
> > if (c == PqReplMsg_WALData)
> > {
> > ...
> > apply_dispatch(&s);
> > }
> > else if (c == LOGICAL_REP_MSG_INTERNAL_MESSAGE)
> > {
> > /* Handle the internal message. */
> > apply_handle_internal_message(&s);
> > }
> >
> > Shveta's patch does something similar but adds an extra parameter to
> > apply_dispatch to control whether the function reads the first byte or
> > uses a passed-in byte. I'm not sure if changing the interface is worth
> > it, as it seems to complicate apply_dispatch() unnecessarily.
> >
> > - Option 3: Used in the older V12 patch.

Same here, I meant V11.

> >
> > At the code level, I personally prefer Option 3, but I understand the
> > reluctance to add internal values to LogicalRepMsgType. So, I'm not
> > sure any of the proposed alternatives are clearly better.

Best Regards,
Hou zj