Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3gL9-0001dk-Ey for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 13:21:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j3gL7-0003XN-Nk for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 13:21:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3gL7-0003XG-BP for pgsql-hackers@lists.postgresql.org; Mon, 17 Feb 2020 13:21:33 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j3gL0-0004fd-Lc for pgsql-hackers@postgresql.org; Mon, 17 Feb 2020 13:21:32 +0000 Received: from hnk.local (sp49-97-93-217.msc.spmode.ne.jp [49.97.93.217]) by oss.nttdata.com (Postfix) with ESMTPSA id B26A46050F; Mon, 17 Feb 2020 22:21:23 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.101.5 at oss.nttdata.com Subject: Re: Wait event that should be reported while waiting for WAL archiving to finish To: Michael Paquier Cc: Robert Haas , "pgsql-hackers@postgresql.org" References: <20200213032804.GB1520@paquier.xyz> <949931aa-4ed4-d867-a7b5-de9c02b2292b@oss.nttdata.com> <20200213073035.GI1520@paquier.xyz> <61477660-dded-2550-b101-c76a2f864806@oss.nttdata.com> <20200217094857.GB115140@paquier.xyz> From: Fujii Masao Message-ID: Date: Mon, 17 Feb 2020 22:21:23 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200217094857.GB115140@paquier.xyz> Content-Type: text/plain; charset=windows-1252; 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/02/17 18:48, Michael Paquier wrote: > On Mon, Feb 17, 2020 at 04:30:00PM +0900, Fujii Masao wrote: >> On 2020/02/14 23:43, Robert Haas wrote: >>> On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao >>> wrote: >>>> Fixed. Thanks for the review! >>> >>> I think it would be safer to just report the wait event during >>> pg_usleep(1000000L) rather than putting those calls around the whole >>> loop. It does not seem impossible that ereport() or >>> CHECK_FOR_INTERRUPTS() could do something that reports a wait event >>> internally. > > CHECK_FOR_INTERRUPTS() would reset the event wait state. Hm.. You > may be right about the WARNING and it would be better to not rely on > that. Do you remember the states which may be triggered? > >> OK, so I attached the updated version of the patch. >> Thanks for the review! > > Actually, I have some questions: > 1) Should a new wait event be added in recoveryPausesHere()? That > would be IMO useful. Yes, it's useful, I think. But it's better to implement that as a separate patch. > 2) Perhaps those two points should be replaced with WaitLatch(), where > we would use the new wait events introduced? For what? Maybe it should, but I'm not sure it's worth the trouble. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters