Re: post-freeze damage control
От | David Steele |
---|---|
Тема | Re: post-freeze damage control |
Дата | |
Msg-id | bf6372c1-b9af-4dea-a054-895e2870b6cc@pgmasters.net обсуждение исходный текст |
Ответ на | Re: post-freeze damage control (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: post-freeze damage control
Re: post-freeze damage control |
Список | pgsql-hackers |
On 4/11/24 20:26, Tomas Vondra wrote: > > On 4/11/24 03:52, David Steele wrote: >> On 4/11/24 10:23, Tom Kincaid wrote: >>> >>> The extensive Beta process we have can be used to build confidence we >>> need in a feature that has extensive review and currently has no known >>> issues or outstanding objections. >> >> I did have objections, here [1] and here [2]. I think the complexity, >> space requirements, and likely performance issues involved in restores >> are going to be a real problem for users. Some of these can be addressed >> in future releases, but I can't escape the feeling that what we are >> releasing here is half-baked. > > I haven't been part of those discussions, and that part of the thread is > a couple months old already, so I'll share my view here instead. > > I do not think it's half-baked. I certainly agree there are limitations, > and there's all kinds of bells and whistles we could add, but I think > the fundamental infrastructure is corrent and a meaningful step forward. > Would I wish it to handle .tar for example? Sure I would. But I think > it's something we can add in the future - if we require all of this to > happen in a single release, it'll never happen. Fair enough, but the current release is extremely limited and it would be best if that was well understood by users. > 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. 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. Regards, -David
В списке pgsql-hackers по дате отправления: