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 1jMAiZ-0005by-4P for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Apr 2020 13:26:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jMAiX-0004di-VV for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Apr 2020 13:26:09 +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 1jMAiX-0004db-H7 for pgsql-bugs@lists.postgresql.org; Wed, 08 Apr 2020 13:26:09 +0000 Received: from mail.dalibo.com ([212.85.157.172]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMAiU-0007xz-Rd for pgsql-bugs@lists.postgresql.org; Wed, 08 Apr 2020 13:26:08 +0000 Received: from firost (larco.ioguix.net [82.66.0.6]) by mail.dalibo.com (Postfix) with ESMTPSA id 041C52025C; Wed, 8 Apr 2020 15:26:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dalibo.com; s=a; t=1586352364; bh=NFhx8pVXlgd4eWNo3rYPRTc15fwD/EloNgqmxmwBUsc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=P+kJIc73+zmXA6OXhHEeT5VRLwPWvSM/ji7sgbpnFKjt9TKa97eFo7SRO99wmPLr0 E5yEQu/k2/JOfWz024vFKDxzLgdFiEVMOOrD9Lp6O1mJpQEkfpbJP40OEwYsOVmViL f57TLB7YLeJnwMmq0TXOloesuJq9Y5VnuOyiuH50= Date: Wed, 8 Apr 2020 15:26:03 +0200 From: Jehan-Guillaume de Rorthais To: Kyotaro Horiguchi Cc: masao.fujii@oss.nttdata.com, pgsql-bugs@lists.postgresql.org, michael@paquier.xyz Subject: Re: [BUG] non archived WAL removed during production crash recovery Message-ID: <20200408152603.4e527053@firost> In-Reply-To: <20200408.173909.874800874546158298.horikyota.ntt@gmail.com> References: <20200403182625.0fccc6fd@firost> <4d48dbdb-e1db-a2d6-2fb2-c2a66efa7818@oss.nttdata.com> <20200407171736.61906608@firost> <20200408.173909.874800874546158298.horikyota.ntt@gmail.com> Organization: Dalibo MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, 08 Apr 2020 17:39:09 +0900 (JST) Kyotaro Horiguchi wrote: > At Tue, 7 Apr 2020 17:17:36 +0200, Jehan-Guillaume de Rorthais > wrote in > > > +/* Recovery state */ > > > +typedef enum RecoveryState > > > +{ > > > + NOT_IN_RECOVERY = 0, > > > + IN_CRASH_RECOVERY, > > > + IN_ARCHIVE_RECOVERY > > > +} RecoveryState; > > I'm not sure the complexity is required here. Are we asuume that > archive_mode can be changed before restarting? I assume it can yes. Eg., one can restore a PITR backup as a standby and change the value of archive_mode to either off, on or always. > At Thu, 2 Apr 2020 15:49:15 +0200, Jehan-Guillaume de Rorthais > wrote in > > > Ok, so our *current* consensus seems the followings. Right? > > > > > > - If archive_mode=off, any WAL files with .ready files are removed in > > > crash recovery, archive recoery and standby mode. > > > > yes > > If archive_mode = off no WAL files are marked as ".ready". Sure, on the primary side. What if you build a standby from a backup with archive_mode=on with some .ready files in there? > > > - If archive_mode=on, WAL files with .ready files are removed only in > > > standby mode. In crash recovery and archive recovery cases, they keep > > > remaining and would be archived after recovery finishes (i.e., during > > > normal processing). > > > > yes > > > > > - If archive_mode=always, in crash recovery, archive recovery and > > > standby mode, WAL files with .ready files are archived if WAL archiver > > > is running. > > > > yes > > So if we assume archive_mode won't be changed after a crash before > restarting, if archive_mode = on on a standy, WAL files are not marked > as ".ready". .ready files can be inherited from the old primary when building the standby, depending on the method. See previous explanations from Fujii-san: https://www.postgresql.org/message-id/flat/ca964b3a-61a0-902e-c7b3-3abbc01a921f%40oss.nttdata.com#ddd6cbad6c5e576e2e1ae53868ca3eea > If it is "always", WAL files that are to be archived are > marked as ".ready". Finally, the condition reduces to: > > If archiver is running, archive ".ready" files. Otherwise ignore > ".ready" and just remove WAL files after use. > > > > > That is, WAL files with .ready files are removed when either > > > archive_mode!=always in standby mode or archive_mode=off. > > > > sounds fine to me. > > That situation implies that archive_mode has been changed. Why? archive_mode may have been "always" on the primary when eg. a snapshot has been created. Regards,