Re: post-freeze damage control

From: David Steele <david(at)pgmasters(dot)net>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Stefan Fercot <stefan(dot)fercot(at)protonmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: post-freeze damage control
Date: 2024-04-12 23:03:28
Message-ID: f49053da-100e-45f2-ab67-08ab0ddacaca@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2024-04-12 23:09:21 Re: Reports on obsolete Postgres versions
Previous Message David Steele 2024-04-12 22:44:29 Re: Add notes to pg_combinebackup docs