Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruhUN-0075Ol-Ik for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 23:36:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ruhUM-00AAIT-Pz for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 23:36:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruhUM-00AAIF-Fx for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 23:36:22 +0000 Received: from mail.thelabyrinth.net ([45.56.70.56]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruhUJ-002G2x-BO for pgsql-hackers@postgresql.org; Wed, 10 Apr 2024 23:36:21 +0000 Received: from [10.5.0.2] (unknown [31.222.254.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dsteele) by mail.thelabyrinth.net (Postfix) with ESMTPSA id 19B6054662; Wed, 10 Apr 2024 23:36:15 +0000 (UTC) Message-ID: Date: Thu, 11 Apr 2024 09:36:11 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: post-freeze damage control To: Michael Paquier Cc: "Andrey M. Borodin" , Alvaro Herrera , Stefan Fercot , Robert Haas , Tomas Vondra , "pgsql-hackers@postgresql.org" References: <202404091545.7zont3umry74@alvherre.pgsql> <4D31BF67-4138-41DC-831D-4BCE0466A59F@yandex-team.ru> Content-Language: en-US From: David Steele In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/10/24 09:50, Michael Paquier wrote: > On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote: >> Even so, only keeping WAL for the last backup is a dangerous move in any >> case. Lots of things can happen to a backup (other than bugs in the >> software) so keeping WAL back to the last full (or for all backups) is >> always an excellent idea. > > Yeah, that's an excellent practive, but is why I'm less worried for > this feature. The docs at [1] caution about "not to remove earlier > backups if they might be needed when restoring later incremental > backups". Like Alvaro said, should we insist a bit more about the WAL > retention part in this section of the docs, down to the last full > backup? I think that would make sense in general. But if we are doing it because we lack confidence in the incremental backup feature maybe that's a sign that the feature should be released as experimental (or not released at all). Regards, -David