Re: Wrong usage of pqMsg_Close message code? - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Wrong usage of pqMsg_Close message code?
Date
Msg-id 20230829161555.GB2136737@nathanxps13
Whole thread Raw
In response to Re: Wrong usage of pqMsg_Close message code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Wrong usage of pqMsg_Close message code?
List pgsql-hackers
Hi everyone,

Thanks for the report.  I'll get this fixed up.  My guess is that this was
leftover from an earlier version of the patch that used the same macro for
identical protocol characters.

On Tue, Aug 29, 2023 at 10:01:47AM -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Actually, this may be OK as well as it stands.  One can also say that
>> the parallel processing is out of this scope, being used only
>> internally.  I cannot keep wondering whether we should put more
>> efforts in documenting the parallel worker/leader protocol.  That's
>> internal to the backend and out of the scope of this thread, still..
> 
> Yeah.  I'm not sure whether the leader/worker protocol needs better
> documentation, but the parts of it that are not common with the
> frontend protocol should NOT be documented in protocol.sgml.
> That would just confuse authors of frontend code.
> 
> I don't mind having constants for the leader/worker protocol in
> protocol.h, as long as they're in a separate section that's clearly
> marked as relevant only for server-internal parallelism.

+1, I left the parallel stuff (and a couple other things) out in the first
round to avoid prolonging the naming discussion, but we can continue to add
to protocol.h.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: broken master regress tests
Next
From: Nathan Bossart
Date:
Subject: Re: pg_stat_get_backend_subxact() and backend IDs?