Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIaXw-00082J-EJ for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Sep 2020 16:44:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kIaXv-0005Ks-CI for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Sep 2020 16:44:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIaXv-0005Kl-5B for pgsql-hackers@lists.postgresql.org; Wed, 16 Sep 2020 16:44:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIaXo-0007zY-TE for pgsql-hackers@lists.postgresql.org; Wed, 16 Sep 2020 16:44:38 +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 08GGiT5H1633418; Wed, 16 Sep 2020 12:44:29 -0400 From: Tom Lane To: Alvaro Herrera cc: Michael Paquier , pgsql-hackers@lists.postgresql.org Subject: Re: Gripes about walsender command processing In-reply-to: <20200916163633.GA9907@alvherre.pgsql> References: <20200916163633.GA9907@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Wed, 16 Sep 2020 13:36:33 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1633416.1600274669.1@sss.pgh.pa.us> Date: Wed, 16 Sep 2020 12:44:29 -0400 Message-ID: <1633417.1600274669@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > On 2020-Sep-15, Alvaro Herrera wrote: >> I overlooked this in 2f9661311b83. From this perspective, I agree it >> looks wrong. We still have to send *some* completion tag (the 'C' >> message), but maybe we can invent a separate entry point in dest.c for >> that -- EndReplicationCommand() or some such -- that takes values from a >> separate enum? > It seems simpler than that actually; we don't need to build a lot of > infrastructure. This looks moderately reasonable to me. However, with the process title reporting I want to add, we're going to end up with a switch that looks like case T_IdentifySystemCmd: + set_ps_display("IDENTIFY_SYSTEM"); IdentifySystem(); + EndReplicationCommand("IDENTIFY_SYSTEM"); break; case T_BaseBackupCmd: + set_ps_display("BASE_BACKUP"); PreventInTransactionBlock(true, "BASE_BACKUP"); SendBaseBackup((BaseBackupCmd *) cmd_node); + EndReplicationCommand("BASE_BACKUP"); break; which is starting to look a bit repetitive and copy-pasteo-prone. I don't see an easy way to improve on it though. The only obvious alternative would be to put another switch before the main one that just fills a "const char *cmdtag" variable, but that seems ugly. regards, tom lane