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.92) (envelope-from ) id 1jE2Oe-0001cc-1W for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2020 02:56:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jE2Oc-0006eX-Gu for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2020 02:55:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jE2Oc-0006eQ-84 for pgsql-hackers@lists.postgresql.org; Tue, 17 Mar 2020 02:55:58 +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 1jE2OU-0001fw-9x for pgsql-hackers@postgresql.org; Tue, 17 Mar 2020 02:55:57 +0000 Received: from hnk.local (sp49-97-94-94.msc.spmode.ne.jp [49.97.94.94]) by oss.nttdata.com (Postfix) with ESMTPSA id E5570600F7; Tue, 17 Mar 2020 11:55:43 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at oss.nttdata.com Subject: Re: RecoveryWalAll and RecoveryWalStream wait events To: Atsushi Torikoshi Cc: Kyotaro Horiguchi , PostgreSQL-development References: <124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.com> <20200218.142016.2107516686265665330.horikyota.ntt@gmail.com> <2ea0c6f1-adcd-f2a2-fe5a-92376ad38432@oss.nttdata.com> From: Fujii Masao Message-ID: Date: Tue, 17 Mar 2020 11:55:43 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/03/15 0:06, Atsushi Torikoshi wrote: > On 2020/02/19 21:46 Fujii Masao >: > >> I agree to the former, I think RecoveryWalInterval works well enough. > >RecoveryWalInterval sounds confusing to me... > > IMHO as a user, I prefer RecoveryRetrieveRetryInterval because > it's easy to understand this wait_event is related to the > parameter 'wal_retrieve_retry_interval'. > > Also from the point of balance, the explanation of > RecoveryRetrieveRetryInterval is lengthy, but I > sometimes feel explanations of wait_events in the > manual are so simple that it's hard to understand > well. +1 to document them more. It's not easy task, though.. > >    Waiting when WAL data is not available from any kind of sources > >    (local, archive or stream) before trying again to retrieve WAL data, > > I think 'local' means pg_wal here, but the comment on > WaitForWALToBecomeAvailable() says checking pg_wal in > standby mode is 'not documented', so I'm a little bit worried > that users may be confused. This logic seems to be documented in high-availability.sgml. But, anyway, you think that "pg_wal" should be used instead of "local" here? Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters