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 1jQQeq-0002BI-Ch for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 07:15:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jQQeo-00060l-QG for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 07:15:54 +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 1jQQeo-00060e-GM for pgsql-hackers@lists.postgresql.org; Mon, 20 Apr 2020 07:15:54 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jQQei-0001uo-2k for pgsql-hackers@postgresql.org; Mon, 20 Apr 2020 07:15:54 +0000 Received: by mail-pj1-x1035.google.com with SMTP id a7so3829376pju.2 for ; Mon, 20 Apr 2020 00:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=B+dnRNqButRafijpydlqVkq7sBtW3Qjy1NzOUh81XFQ=; b=vH3/cHljhCijQNB2/P/q2fv8pMEYLOStveJjTdwGd5oqI4j42Vd2859BOQKW5w4u0O 5NS9sthMIdJlFEY5fnUCf/geUT9zF5853fkUzHhDT3sKLPixtAoIbdw+35vhDDkbSf1y 68EY1hAk5ySLrBzJ6vB2zc68PfOBt2tPUogt8NrTHOlqxLRxV+ROOPBVzkIue/Sh6R/8 6v6ThGMh1fPSSKDHDImV4gos61lKqo0y4Ku0zm43o+/bbNL6FIBe8hVjzZx9ffM4R2VW kvRvbYpuY2vu5AENxdWIuN/nh5zZwk5GKks1u+cZdQHOJixlw7aS49eTrl0Ltj2RGO5p kMqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=B+dnRNqButRafijpydlqVkq7sBtW3Qjy1NzOUh81XFQ=; b=Ttq1fl7sSPuLSC7z+hyBgr1rYKGQCEGHCpKQDYh/TGcyuR3Xw8D8B5e6mg9MLmkfYr jSsvKGQChmdf45gEpCEBm4cDQpFD/Oi4jGY6qLG9ck7QyT+63tFV1OMC0g7nlnJf4EOV vmtJEs0gzIrh7TnQ3Tuc1O+LRIgvoNfwyOzj70nCD+n8Y7rcnCHVVO1/Qb8SQ2c5ipWE r0lWjm6YnaCCDyzBVLaUEaOMJntrfWzb6ifBK+3Hceh+3j488JX7AX/rY/ROHLhcGIE5 TOd7aKL1xNCErbEPMlVWD1XGSc2v2THXp4Ve0GjbTcPtGSvZqZnOCWywWH+LQwz3Kbsy +67g== X-Gm-Message-State: AGi0PubOh/n3dLbwE6OpD324E52288rRN1mxJJCpeqRyro3Q6KLIM8yQ KelTz3rJvC9GzAL/Y2RxcFg= X-Google-Smtp-Source: APiQypLYhGvhcrEj+bWkKOfwdnjcRxqiuyc4M0Fs8X/gZ2/hPi/Hwg1JXsILuMcO1S8MiJo3dYuVeQ== X-Received: by 2002:a17:90a:9504:: with SMTP id t4mr20267437pjo.21.1587366944975; Mon, 20 Apr 2020 00:15:44 -0700 (PDT) Received: from localhost (ag027197.dynamic.ppp.asahi-net.or.jp. [157.107.27.197]) by smtp.gmail.com with ESMTPSA id d7sm208202pfa.106.2020.04.20.00.15.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2020 00:15:43 -0700 (PDT) Date: Mon, 20 Apr 2020 16:15:40 +0900 (JST) Message-Id: <20200420.161540.916795157446565832.horikyota.ntt@gmail.com> To: noah@leadboat.com Cc: masao.fujii@oss.nttdata.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org Subject: Re: 001_rep_changes.pl stalls From: Kyotaro Horiguchi In-Reply-To: <20200418070142.GA1075445@rfd.leadboat.com> References: <20200417054146.GA1061007@rfd.leadboat.com> <20200418070142.GA1075445@rfd.leadboat.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk At Sat, 18 Apr 2020 00:01:42 -0700, Noah Misch wrote in > On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote: > > At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi wrote in > > > By the way, if latch is consumed in WalSndLoop, succeeding call to > > > WalSndWaitForWal cannot be woke-up by the latch-set. Doesn't that > > > cause missing wakeups? (in other words, overlooking of wakeup latch). > > > > - Since the only source other than timeout of walsender wakeup is latch, > > - we should avoid wasteful consuming of latch. (It is the same issue > > - with [1]). > > > > + Since walsender is wokeup by LSN advancement via latch, we should > > + avoid wasteful consuming of latch. (It is the same issue with [1]). > > > > > > > If wakeup signal is not remembered on walsender (like > > > InterruptPending), WalSndPhysical cannot enter a sleep with > > > confidence. > > No; per latch.h, "What must be avoided is placing any checks for asynchronous > events after WaitLatch and before ResetLatch, as that creates a race > condition." In other words, the thing to avoid is calling ResetLatch() > without next examining all pending work that a latch would signal. Each > walsender.c WaitLatch call does follow the rules. I didn't meant that, of course. I thought of more or less the same with moving the trigger from latch to signal then the handler sets a flag and SetLatch(). If we use bare latch, we should avoid false entering to sleep, which also makes thinks compolex. regards. -- Kyotaro Horiguchi NTT Open Source Software Center