Message-ID: <f49053da-100e-45f2-ab67-08ab0ddacaca@pgmasters.net>
Date: Sat, 13 Apr 2024 09:03:28 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: post-freeze damage control
Content-Language: en-US
To: Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Tom Kincaid <tomjohnkincaid@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Stefan Fercot <stefan.fercot@protonmail.com>,
 Robert Haas <robertmhaas@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <202404091545.7zont3umry74@alvherre.pgsql>
 <4D31BF67-4138-41DC-831D-4BCE0466A59F@yandex-team.ru>
 <f2e7f916-b32f-48ac-8200-7a803a241b5e@pgmasters.net>
 <ZhXUYBXTWvF4OaPm@paquier.xyz>
 <e61e8b08-e67e-4d45-9e66-1eaa82d49f16@pgmasters.net>
 <CAKPRjUMVH+YDxEUdHqBPQov9oiDek=bJMAKLQotPYfVZ=i3AKQ@mail.gmail.com>
 <cab01e3d-bf5d-4750-b67f-8c1b2f74d6ea@pgmasters.net>
 <71fcff9e-371b-4f6a-bd34-bfe5cffb864f@enterprisedb.com>
 <bf6372c1-b9af-4dea-a054-895e2870b6cc@pgmasters.net>
 <4fb270c4-2ae0-4439-92e5-2941e73122ca@enterprisedb.com>
From: David Steele <david@pgmasters.net>
In-Reply-To: <4fb270c4-2ae0-4439-92e5-2941e73122ca@enterprisedb.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/f49053da-100e-45f2-ab67-08ab0ddacaca%40pgmasters.net>
Precedence: bulk

On 4/12/24 22:12, Tomas Vondra wrote:
> On 4/11/24 23:48, David Steele wrote:
>> On 4/11/24 20:26, Tomas Vondra wrote:
 >>
>>> FWIW that discussion also mentions stuff that I think the feature should
>>> not do. In particular, I don't think the ambition was (or should be) to
>>> make pg_basebackup into a stand-alone tool. I always saw pg_basebackup
>>> more as an interface to "backup steps" correctly rather than a complete
>>> backup solution that'd manage backup registry, retention, etc.
>>
>> Right -- this is exactly my issue. pg_basebackup was never easy to use
>> as a backup solution and this feature makes it significantly more
>> complicated. Complicated enough that it would be extremely difficult for
>> most users to utilize in a meaningful way.
> 
> Perhaps, I agree we could/should try to do better job to do backups, no
> argument there. But I still don't quite see why introducing such
> infrastructure to "manage backups" should be up to the patch adding
> incremental backups. I see it as something to build on top of
> pg_basebackup/pg_combinebackup, not into those tools.

I'm not saying that managing backups needs to be part of pg_basebackup, 
but I am saying without that it is not a complete backup solution. 
Therefore introducing advanced features that the user then has to figure 
out how to manage puts a large burden on them. Implementing 
pg_combinebackup inefficiently out of the gate just makes their life harder.

>> But they'll try because it is a new pg_basebackup feature and they'll
>> assume it is there to be used. Maybe it would be a good idea to make it
>> clear in the documentation that significant tooling will be required to
>> make it work.
> 
> Sure, I'm not against making it clearer pg_combinebackup is not a
> complete backup solution, and documenting the existing restrictions.

Let's do that then. I think it would make sense to add caveats to the 
pg_combinebackup docs including space requirements, being explicit about 
the format required (e.g. plain), and also possible mitigation with COW 
filesystems.

Regards,
-David