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 1nAvjG-0006bX-35 for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Jan 2022 15:21:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nAvij-00072t-6b for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Jan 2022 15:20:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAvii-00072R-UF for pgsql-bugs@lists.postgresql.org; Fri, 21 Jan 2022 15:20:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAvic-0002Kv-Er for pgsql-bugs@lists.postgresql.org; Fri, 21 Jan 2022 15:20:56 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 20LFKklD1183621; Fri, 21 Jan 2022 10:20:46 -0500 From: Tom Lane To: "David G. Johnston" cc: B Ganesh Kishan , "pgsql-bugs@lists.postgresql.org" , Meera Nair Subject: Re: BUG #17375: RECOVERY TARGET TIME RESTORE IS FAILING TO START SERVER In-reply-to: References: <17375-981fa49736cc1ae1@postgresql.org> Comments: In-reply-to "David G. Johnston" message dated "Fri, 21 Jan 2022 08:10:24 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1183619.1642778446.1@sss.pgh.pa.us> Date: Fri, 21 Jan 2022 10:20:46 -0500 Message-ID: <1183620.1642778446@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Fri, Jan 21, 2022 at 4:20 AM B Ganesh Kishan > wrote: >> The problem is that we are providing a time target that Postgres does not >> know how to reach. This is because there are no transactions in between the >> backups. > I don't quite follow the overall situation but given your observation and > apparent acceptance of the pre-v13 behavior just don't specify a restore > point and let WAL replay everything. Yeah. If I'm understanding the situation, when you specify a target time that is later than the last transaction available from WAL, older versions silently assumed that stopping with the last available transaction is OK. Newer ones complain because it's not clear whether that's OK --- in particular, there's no good way to be sure that no WAL is missing. On the whole I think that's a good change. I can sympathize with the complaint that it creates additional complexity for restore scripts, but I'm a little dubious that this is something you'd be wanting to script anyway. regards, tom lane