On Thu, Sep 10, 2026 at 01:14:55PM -0400, Tom Lane wrote:
> Sami Imseih <samimseih.pg@gmail.com> writes:
>> On Thu, Sep 10, 2026 at 9:30 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> All of the options I've seen listed in this thread so far involve changing
>>> the part after the PqMsg_ prefix, but given we now have PqReplMsg_ and
>>> PqBackupMsg_, I'm thinking it'd be better to give parallel worker messages
>>> their own prefix. That seems to act as a sort of class or namespace for
>>> the message. Maybe something like PqParallelMsg_Progress would work here.
>
>> I think PqParallelMsg_Progress makes sense. The attached does this.
>
> +1
As I'm writing the commit message for this, I'm remembering why I
originally went with "PqMsg" for this one. Parallel workers reuse a bunch
of "regular" message types for roughly the same purpose as non-parallel
uses, so (with this commit applied) a function like
ProcessParallelMessage() would handle a bunch of "PqMsg" message types and
one "PqParallelMsg" type. I think the obvious way to resolve that
inconsistency is to duplicate those macros and give them the parallel
prefix, but I'm not sure that's a worthwhile endeavor. Those characters
have roughly the same meaning for parallel workers/leaders as they do
elsewhere, so there's no real gain in code readability. I'm content to
commit Sami's patch and let it be, but if folks would rather I straighten
things out further, I can do so.
--
nathan
