Re: Wrong usage of pqMsg_Close message code?

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: Wrong usage of pqMsg_Close message code?
Дата
Msg-id 20230829161555.GB2136737@nathanxps13
обсуждение исходный текст
Ответ на Re: Wrong usage of pqMsg_Close message code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Wrong usage of pqMsg_Close message code?
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: broken master regress tests
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: pg_stat_get_backend_subxact() and backend IDs?