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 1jK1IG-0004mE-W4 for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Apr 2020 14:58:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jK1IF-0002H5-UF for pgsql-bugs@arkaria.postgresql.org; Thu, 02 Apr 2020 14:58:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jK1IF-0002Gw-OS for pgsql-bugs@lists.postgresql.org; Thu, 02 Apr 2020 14:58:07 +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 1jK1ID-0000iU-CU for pgsql-bugs@lists.postgresql.org; Thu, 02 Apr 2020 14:58:06 +0000 Received: from hnk.local (p2421237-ipbf2725funabasi.chiba.ocn.ne.jp [122.24.33.237]) by oss.nttdata.com (Postfix) with ESMTPSA id 48CC76003F; Thu, 2 Apr 2020 23:58:01 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at oss.nttdata.com Subject: Re: [BUG] non archived WAL removed during production crash recovery To: Jehan-Guillaume de Rorthais , Kyotaro Horiguchi Cc: pgsql-bugs@lists.postgresql.org, michael@paquier.xyz References: <20200401181735.11100908@firost> <20200402.130443.1791362864704140391.horikyota.ntt@gmail.com> <20200402.130734.613319908534820379.horikyota.ntt@gmail.com> <20200402150234.278ae845@firost> From: Fujii Masao Message-ID: Date: Thu, 2 Apr 2020 23:58:00 +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: <20200402150234.278ae845@firost> 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/02 22:02, Jehan-Guillaume de Rorthais wrote: > On Thu, 02 Apr 2020 13:07:34 +0900 (JST) > Kyotaro Horiguchi wrote: > >> Sorry, it was quite ambiguous. >> >> At Thu, 02 Apr 2020 13:04:43 +0900 (JST), Kyotaro Horiguchi >> wrote in >>> At Wed, 1 Apr 2020 18:17:35 +0200, Jehan-Guillaume de Rorthais >>> wrote in >>>> Please, find in attachment a patch implementing this. >>> >>> The patch partially reintroduces the issue the patch have >>> fixed. Specifically a standby running a crash recovery wrongly marks a >>> WAL file as ".ready" if it is extant in pg_wal without accompanied by >>> .ready file. >> >> The patch partially reintroduces the issue the commit 78ea8b5daa have >> fixed. Specifically a standby running a crash recovery wrongly marks a >> WAL file as ".ready" if it is extant in pg_wal without accompanied by >> .ready file. > > As far as I understand StartupXLOG(), NOT_IN_RECOVERY and IN_CRASH_RECOVERY are > only set for production clusters, not standby ones. DB_IN_CRASH_RECOVERY can be set even in standby mode. For example, if you start the standby from the cold backup of the primary, since InArchiveRecovery is false at the beginning of the recovery, DB_IN_CRASH_RECOVERY is set in that moment. But then after all the valid WAL in pg_wal have been replayed, InArchiveRecovery is set to true and DB_IN_ARCHIVE_RECOVERY is set. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION