| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pavel(dot)stehule(at)gmail(dot)com, aleksander(at)timescale(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Wrong usage of pqMsg_Close message code? |
| Date: | 2023-08-29 14:01:47 |
| Message-ID: | 1004809.1693317707@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-08-29 14:14:45 | Re: Restoring default privileges on objects |
| Previous Message | Jelte Fennema | 2023-08-29 13:55:05 | Re: Allow specifying a dbname in pg_basebackup connection string |