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 1jQTbX-00087f-6M for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 10:24:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jQTbW-0002kT-2A for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Apr 2020 10:24:42 +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 1jQTbV-0002iX-R6 for pgsql-hackers@lists.postgresql.org; Mon, 20 Apr 2020 10:24:41 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQTbO-0003k2-25 for pgsql-hackers@postgresql.org; Mon, 20 Apr 2020 10:24:41 +0000 Received: from hnk.local (p2421237-ipbf2725funabasi.chiba.ocn.ne.jp [122.24.33.237]) by oss.nttdata.com (Postfix) with ESMTPSA id B9E5360530; Mon, 20 Apr 2020 19:24:28 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at oss.nttdata.com Subject: Re: 001_rep_changes.pl stalls To: Noah Misch Cc: Kyotaro Horiguchi , Tom Lane , pgsql-hackers@postgresql.org References: <20200406063649.GA3738151@rfd.leadboat.com> <20200414013849.GA886648@rfd.leadboat.com> <8807.1586828716@sss.pgh.pa.us> <20200417054146.GA1061007@rfd.leadboat.com> <20200418070142.GA1075445@rfd.leadboat.com> <20200420070215.GA1395671@rfd.leadboat.com> From: Fujii Masao Message-ID: <7492aa54-dabf-3791-cbc4-e653760a2288@oss.nttdata.com> Date: Mon, 20 Apr 2020 19:24:28 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200420070215.GA1395671@rfd.leadboat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/04/20 16:02, Noah Misch wrote: > On Mon, Apr 20, 2020 at 02:30:08PM +0900, Fujii Masao wrote: >> + * Block if we have unsent data. XXX For logical replication, let >> + * WalSndWaitForWal(), handle any other blocking; idle receivers need >> + * its additional actions. For physical replication, also block if >> + * caught up; its send_data does not block. >> >> It might be better to s/WalSndWaitForWal()/send_data()? Because not only >> WalSndWaitForWal() but also WalSndWriteData() seems to handle the blocking. >> WalSndWriteData() is called also under send_data, i.e., XLogSendLogical(). > > Thanks for reviewing. WalSndWriteData() blocks when we have unsent data, > which is the same cause for blocking in WalSndLoop(). Since the comment you > quote says we let WalSndWaitForWal() "handle any other blocking", I don't > think your proposed change makes it more correct. I was misreading this as something like "any other blocking than the blocking in WalSndLoop()". Ok, I have no more comments on the patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION