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
