RE: Parallel Apply - Mailing list pgsql-hackers

On Thursday, April 23, 2026 6:05 PM shveta malik <shveta.malik@gmail.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