Re: post-freeze damage control - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: post-freeze damage control |
Date | |
Msg-id | 86ce0459-b879-4320-9e10-d38510810d56@enterprisedb.com Whole thread Raw |
In response to | Re: post-freeze damage control (David Steele <david@pgmasters.net>) |
Responses |
Re: post-freeze damage control
|
List | pgsql-hackers |
On 4/13/24 01:03, David Steele wrote: > 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. > I agree with this in general, but I fail to see how it'd be the fault of this patch. It merely extends what pg_basebackup did before, so if it's not a complete solution now, it wasn't a complete solution before. Sure, I 100% agree it'd be great to have a more efficient pg_combinebackup with fewer restrictions. But if we make these limitations clear, I think it's better to have this than having nothing. >>> 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. > OK. I'll add this as an open item, for me and Robert. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: