On Thu, Sep 10, 2026 at 01:14:55PM -0400, Tom Lane wrote: > Sami Imseih <[email protected]> writes: >> On Thu, Sep 10, 2026 at 9:30 AM Nathan Bossart <[email protected]> >> 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
