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 1jEoli-0007g3-5A for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2020 06:35:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jEolg-0002NI-Ie for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2020 06:35:00 +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 1jEolg-0002LL-9o for pgsql-hackers@lists.postgresql.org; Thu, 19 Mar 2020 06:35:00 +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 1jEolc-0004HR-QD for pgsql-hackers@postgresql.org; Thu, 19 Mar 2020 06:34:59 +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 B979060546; Thu, 19 Mar 2020 15:34:49 +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: <2811dcd9-2928-a08c-7034-23c021dbc0ec@oss.nttdata.com> Date: Thu, 19 Mar 2020 15:34:49 +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/18 22:37, Atsushi Torikoshi wrote: > > On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao > wrote: > > > I meant the following part in the doc. > > --------------------- > At startup, the standby begins by restoring all WAL available in the archive > location, calling restore_command. Once it reaches the end of WAL available > there and restore_command fails, it tries to restore any WAL available in the > pg_wal directory. If that fails, and streaming replication has been configured, > the standby tries to connect to the primary server and start streaming WAL from > the last valid record found in archive or pg_wal. If that fails or streaming > replication is not configured, or if the connection is later disconnected, > the standby goes back to step 1 and tries to restore the file from the archive > again. This loop of retries from the archive, pg_wal, and via streaming > replication goes on until the server is stopped or failover is triggered by a > trigger file. > --------------------- > > > Thanks! > > > It seems the comment on WaitForWALToBecomeAvailable() > > does not go along with the high-availability.sgml, do we need > > modification on the comment on the function? > > No, I think for now. But you'd like to improve the docs? > > > I'll do it. > > >     But, anyway, you think that "pg_wal" should be used instead > > > >     of "local" here? > > > > > > I don't have special opinion here. > > It might be better because high-availability.sgml does not use > > "local" but "pg_wal" for the explanation,  but I also feel it's > > obvious in this context. > > Ok, I changed that from "local" to "pg_wal" in the patch for > the master. Attached is the updated version of the patch. > If you're OK with this, I'd like to commit two patches that I posted > in this thread. > > >  Thanks for your modification and it looks good to me. Pushed! Thanks a lot! Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters