Re: WAL Archiving and base backup - Mailing list pgsql-general
| From | David G. Johnston |
|---|---|
| Subject | Re: WAL Archiving and base backup |
| Date | |
| Msg-id | CAKFQuwb-JkA7ibxGoK7rZjvxb9TMp1VYsa8T44-NafkAd7HRdA@mail.gmail.com Whole thread Raw |
| In response to | Re: WAL Archiving and base backup (Mladen Gogala <gogala.mladen@gmail.com>) |
| List | pgsql-general |
On Sat, Jan 15, 2022 at 5:23 PM Mladen Gogala <gogala.mladen@gmail.com> wrote:
On 1/14/22 16:00, David G. Johnston wrote:I still don't really understand what is so great about it. About its only redeeming feature is a declaration that "it is in core" and that newcomers can just default to it without thinking. I'd rather just play favorites and write "use pgbackrest" in our documentation. Or some hybrid approach where we don't just pick one but instead guide people to the community solutions that are out there. I don't think I really want the people responsible for core to spend time on writing end-user backup tooling. Their time is much more valuably spent working on the core product.David J.Well, the "without thinking" part of your post can be rephrased as "ease of use". Do database administrators really need to think about which backup software to use? What kind of knowledge will such an evaluation provide? All commercial databases have some form of backup software included into the core database. After all, backup and restore are extremely important functions which IMHO should be provided along with the database software.
I suppose I'm being a bit pessimistic here since if we didn't provide some features that users wanted, and an external tool did, they would probably think about the lack and realize that their needs would be better served by a third-party tool.
In fact we already offer pg_dump/pg_restore and pg_basebackup (which seems like it should have a matching "pg_baserestore" command...) in core. These easy-to-use tools give the DBA the ability to backup their system. So the claim that we lack such tooling is simply incorrect.
An additional consideration is that this kind of application would not benefit from having the same release policies as the core server. It probably shouldn't integrate with our existing commitfest site, buildfarm, etc... It is probably best done as a GUI tool which the project has never produced. It already has serious competition which means our corporate sponsors probably won't be using it for their clients and thus will not be incentivized to contribute to its development. I could go on, but what's the point?
Spending a tiny fraction of the time it would take to develop an in-core interactive backup and restore application gathering up user questions and complaints and proposing patches to the documentation and Wiki would be a better use of time in service to our end users. People make these things work so it isn't a lack of solutions but a lack of knowledge for the inexperienced and part-time DBA crowd. We can and should work toward improving the learning curve experience - and such an endeavor can be done with very little knowledge of PostgreSQL internals and thus is an excellent way for people who don't code C and aren't in a position to code and review core patches to contribute to the project and the broader community.
David J.
David J.
pgsql-general by date: