Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qazI3-00Ars7-TB for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Aug 2023 14:01:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qazI2-007sH7-H4 for pgsql-hackers@arkaria.postgresql.org; Tue, 29 Aug 2023 14:01:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qazI2-007sGs-6h for pgsql-hackers@lists.postgresql.org; Tue, 29 Aug 2023 14:01:53 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qazHz-001bxv-8n for pgsql-hackers@lists.postgresql.org; Tue, 29 Aug 2023 14:01:52 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 37TE1lUX1004810; Tue, 29 Aug 2023 10:01:47 -0400 From: Tom Lane To: Michael Paquier cc: Tatsuo Ishii , pavel.stehule@gmail.com, aleksander@timescale.com, pgsql-hackers@lists.postgresql.org Subject: Re: Wrong usage of pqMsg_Close message code? In-reply-to: References: <20230829.061200.192005411012654565.t-ishii@sranhm.sra.co.jp> <20230829.100424.623781851282219189.t-ishii@sranhm.sra.co.jp> Comments: In-reply-to Michael Paquier message dated "Tue, 29 Aug 2023 16:39:51 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1004808.1693317707.1@sss.pgh.pa.us> Date: Tue, 29 Aug 2023 10:01:47 -0400 Message-ID: <1004809.1693317707@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier 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