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 1pHdfQ-0003LA-HK for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Jan 2023 04:33:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pHdfP-0002qc-Cb for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Jan 2023 04:33:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHdfO-0002q9-TH for pgsql-hackers@lists.postgresql.org; Tue, 17 Jan 2023 04:33:47 +0000 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pHdfM-00079b-IC for pgsql-hackers@lists.postgresql.org; Tue, 17 Jan 2023 04:33:45 +0000 Received: by mail-wr1-x42d.google.com with SMTP id z5so28264989wrt.6 for ; Mon, 16 Jan 2023 20:33:44 -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=DguDd7J+MtjpRex7eV3XuedF/SqQfOdlu9DbPNHkjIw=; b=DfB3f6ISJTt6i4mx4/BHytrMp4ZjVQ+eZaXi/5OTxGHFno2Vug7cLXXo+1E0yz12lx aNEgImqIUlP6RgpNLRvfhmeyzRa24Pca34P99Iwi8icrfP7AJTosebwlupyQRzgRxwt3 R1y8VagrSZ0WmCItkBmO94M4NZKm7rOVkx5QBn9lp6nGlC/Q90Cn+WIjwUw7yq/Ng/+p YVJ6fzMvk0fv4e/nuKyhyS7XymLFNHVYwt6KcYfErcJGQMP1XlObYshEnn4/xL/iqmZo NZekLyGUWgrQjfKjkg6L9NP37ijd+Kphf65oSqOyZLNNZ3nWggKWwc9Ajl0fH1rclLhH eKHQ== 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=DguDd7J+MtjpRex7eV3XuedF/SqQfOdlu9DbPNHkjIw=; b=su797e2FDRLDd4E1SqaU7d/DVTHy1VRlpp5p53eGjpI788Fc8qry9OVo53XmSpFscG E4vNG9yMFhkLrLXkWM3egh7scWmb35wdLRH261TJ03X/rELFWR7ISEO3zWtl3L+cuase FdmzLn40QL3gVOv8E3V7IprTHqoCsmex8+1hdNQUtAZnvfpSMIFKsLacPHte4ixY3SKG eagcBWqjuQUrOu09yT5KQF7SovggicsDKnEOuu+a9Nhuy1xTz849ChMhvzwSl2fZ/KXZ dWNwL61gKXLUWXCAQMG2NcSQikdVbxiKqxAkpajwQit1OKqUCsXyK45y1LesRuEoGhPS JATw== X-Gm-Message-State: AFqh2kqWcZVapDji8jxZCx4EG3N6FQgpSNpdF70e1ztVFql5lbKUEZDo CkttGam8m2zaVUIXDqpUpYUKFZHpBb8xm8uDqM8= X-Google-Smtp-Source: AMrXdXsiylTkfnz7TeyNn9Ugoo9N0JfFgJBxfqP2/6uq9J5uQfMH9X5ZWlSCm1WTL2/5ISw1/TBtKIOWtLUnc3IpxNQ= X-Received: by 2002:a5d:530d:0:b0:2bd:fe5a:b576 with SMTP id e13-20020a5d530d000000b002bdfe5ab576mr43332wrv.668.1673930022563; Mon, 16 Jan 2023 20:33:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 17 Jan 2023 10:03:30 +0530 Message-ID: Subject: Re: Perform streaming logical transactions by background workers and parallel apply To: "houzj.fnst@fujitsu.com" Cc: Peter Smith , Masahiko Sawada , "wangw.fnst@fujitsu.com" , "shiy.fnst@fujitsu.com" , PostgreSQL Hackers , Dilip Kumar , Amit Kapila , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 17, 2023 at 9:07 AM houzj.fnst@fujitsu.com wrote: > > On Tuesday, January 17, 2023 11:32 AM Peter Smith wrote: > > > > On Tue, Jan 17, 2023 at 1:21 PM houzj.fnst@fujitsu.com > > wrote: > > > > > > On Tuesday, January 17, 2023 5:43 AM Peter Smith > > wrote: > > > > > > > > On Mon, Jan 16, 2023 at 5:41 PM Amit Kapila > > > > > > > > wrote: > > > > > > > > > > On Mon, Jan 16, 2023 at 10:24 AM Peter Smith > > > > > > > > > wrote: > > > > > > > > > > > > 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; } > > > > > > > > > > > > > > > > Yeah, this should also work but I feel the current one is explicit > > > > > and more clear. > > > > > > > > OK. > > > > > > > > But, I have one last comment about this function -- I saw there are > > > > already other functions that iterate max_logical_replication_workers > > > > like this looking for things: > > > > - logicalrep_worker_find > > > > - logicalrep_workers_find > > > > - logicalrep_worker_launch > > > > - logicalrep_sync_worker_count > > > > > > > > So I felt this new function (currently called > > > > GetLeaderApplyWorkerPid) ought to be named similarly to those ones. > > > > e.g. call it something like "logicalrep_worker_find_pa_leader_pid". > > > > > > > > > > I am not sure we can use the name, because currently all the API name > > > in launcher that used by other module(not related to subscription) are > > > like AxxBxx style(see the functions in logicallauncher.h). > > > logicalrep_worker_xxx style functions are currently only declared in > > > worker_internal.h. > > > > > > > OK. I didn't know there was another header convention that you were following. > > In that case, it is fine to leave the name as-is. > > Thanks for confirming! > > Attach the new version 0001 patch which addressed all other comments. > > Best regards, > Hou zj Hello Hou-san, 1. Do we need to extend test-cases to review the leader_pid column in pg_stats tables? 2. Do we need to follow the naming convention for 'GetLeaderApplyWorkerPid' like other functions in the same file which starts with 'logicalrep_' thanks Shveta