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 1pHHVm-0004WF-Es for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jan 2023 04:54:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pHHVl-0000lS-Ci for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jan 2023 04:54:21 +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 1pHHVl-0000lJ-3k for pgsql-hackers@lists.postgresql.org; Mon, 16 Jan 2023 04:54:21 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pHHVj-0003Cq-7g for pgsql-hackers@lists.postgresql.org; Mon, 16 Jan 2023 04:54:20 +0000 Received: by mail-lj1-x229.google.com with SMTP id e16so1965282ljn.3 for ; Sun, 15 Jan 2023 20:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i9z+JjN+L1oX19nrbi3E35VSy2cCsmOoVas/hC2TyKs=; b=J29UmeQhPxNWi5Aqq+QhsPvBX6xqbHkoYkaTYtCX1BklHBz9n/+n3R1TZjYVVXMnMt yWchiSk8HHWg9kcmk9er/ZJ5/dVPUecLMdcZlafy9HDHnx2WaIEZQotGNAezPhbo663K WDGHqeBXJDnImDiSwvH9fFGATit+hKQgRd01nGDE3C5X59yPLAIs8WdXDlQEbhYBSI1D Rc9uFEW6YoLNyPGHBAHjwGzq4YKnO8KFAFTBX9ql/q9viLQZbqe1O22AJK78qqUkhtE9 zfFfkZKBbnjGZyaGWwB67YPBfjS5TmsTz3nTAJxDNfvfdcoBOZY/GQfm/5fObfxofAis lnzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i9z+JjN+L1oX19nrbi3E35VSy2cCsmOoVas/hC2TyKs=; b=MYfuUpqlzQor28FA37+HsJvo6OLNJq/0qlmZNLq7U181I58cShPRiUmZ/xgkAvKogp L/Ws1bMu9cyLg5234CwvehrPaqolkaiLMyWtB+V0QeBdy0kVyiIxWn0fMGvJAOXTZE/m HBBARWcdS6SSnwaHj8ypep9zlo1TxjTJcOFswK8rRAQCY0Iph+GAYIjKqGzv2h3KRlVu UMOLqAVXZwwXaypwB1cNFTVusPpk01WzWETmnYdZk4v5BE3liAi67xt0ABX1E//yHm5l DtznGn9VW12kAN58ZcNrvk6VE5+vFt7GkpaDux75QGRvKiNLUn9CVLh2LFc9Zi4xfFW+ gyrw== X-Gm-Message-State: AFqh2kp6PQHPvDM72YcWjD2SyI4JfPoRb7WiDY3LL8qJodHapjQihZ2n j6yw9VGZsPncnzROxU2F992Qye0SufbUPGkhpiabU4UX9hE= X-Google-Smtp-Source: AMrXdXvenDwdPjCaKuhfKHlXQB09r4KDQAV5jKtyWYA2nYeM5XsuT3mXxPPm5JFxEyIf74kvLoeWrbSWrBHDpZMnlzg= X-Received: by 2002:a2e:7c01:0:b0:281:b8f6:e66a with SMTP id x1-20020a2e7c01000000b00281b8f6e66amr1494711ljc.335.1673844857695; Sun, 15 Jan 2023 20:54:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 16 Jan 2023 15:54:00 +1100 Message-ID: Subject: Re: Perform streaming logical transactions by background workers and parallel apply To: Amit Kapila Cc: "houzj.fnst@fujitsu.com" , Masahiko Sawada , shveta malik , "wangw.fnst@fujitsu.com" , "shiy.fnst@fujitsu.com" , PostgreSQL Hackers , Dilip Kumar Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Here are some review comments for v81-0001. ====== Commit Message 1. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. ~ Probably it should not say both "Additionally" and "as well" in the same sentence. ====== src/backend/replication/logical/launcher.c 2. /* + * Return the pid of the leader apply worker if the given pid is the pid of a + * parallel apply worker, otherwise return InvalidPid. + */ +pid_t +GetLeaderApplyWorkerPid(pid_t pid) +{ + int leader_pid = InvalidPid; + int i; + + LWLockAcquire(LogicalRepWorkerLock, LW_SHARED); + + for (i = 0; i < max_logical_replication_workers; i++) + { + LogicalRepWorker *w = &LogicalRepCtx->workers[i]; + + if (isParallelApplyWorker(w) && w->proc && pid == w->proc->pid) + { + leader_pid = w->leader_pid; + break; + } + } + + LWLockRelease(LogicalRepWorkerLock); + + return leader_pid; +} 2a. IIUC the IsParallelApplyWorker macro does nothing except check that the leader_pid is not InvalidPid anyway, so AFAIK this algorithm does not benefit from using this macro because we will want to return InvalidPid anyway if the given pid matches. So the inner condition can just say: if (w->proc && w->proc->pid == pid) { leader_pid = w->leader_pid; break; } ~ 2b. A possible alternative comment. BEFORE Return the pid of the leader apply worker if the given pid is the pid of a parallel apply worker, otherwise return InvalidPid. AFTER If the given pid has a leader apply worker then return the leader pid, otherwise, return InvalidPid. ====== src/backend/utils/adt/pgstatfuncs.c 3. @@ -434,6 +435,16 @@ pg_stat_get_activity(PG_FUNCTION_ARGS) values[28] = Int32GetDatum(leader->pid); nulls[28] = false; } + else + { + int leader_pid = GetLeaderApplyWorkerPid(beentry->st_procpid); + + if (leader_pid != InvalidPid) + { + values[28] = Int32GetDatum(leader_pid); + nulls[28] = false; + } + 3a. There is an existing comment preceding this if/else but it refers only to leaders of parallel groups. Should that comment be updated to mention the leader apply worker too? ~ 3b. It may be unrelated to this patch, but it seems strange to me that the nulls[28]/values[28] assignments are done where they are. Every other nulls/values assignment of this function here is pretty much in the correct numerical order except this one, so IMO this code ought to be relocated to later in this same function. ------ Kind Regards, Peter Smith. Fujitsu Australia.