Re: post-freeze damage control
От | David Steele |
---|---|
Тема | Re: post-freeze damage control |
Дата | |
Msg-id | f49053da-100e-45f2-ab67-08ab0ddacaca@pgmasters.net обсуждение исходный текст |
Ответ на | Re: post-freeze damage control (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: post-freeze damage control
|
Список | 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
В списке pgsql-hackers по дате отправления: