On 03/09/22 11:22, Magnus Hagander wrote: >> It's more than just too confusing, it's actively bad because people will >> actually use it and then end up with backups that don't work. > > +1. > > Or even worse, backups that sometimes work, but not reliably and not > every time. > ... > Pretending something is simple when it's not, is not doing anybody a favor.
Okay, I bow to this reasoning, for the purpose of this patch. Let's just lose the example. >> Documenting everything that pg_basebackup does to make sure that the >> backup is viable might be something to work on if someone is really >> excited about this, but it's not 'dead-simple' and it's darn close to >> the bare minimum, something that none of these simple scripts will come >> anywhere close to being and instead they'll be far less than the >> minimum. > > Yeah, having the full set of steps required documented certainly > wouldn't be a bad thing. I'd say that qualifies as an understatement. While it certainly doesn't have to be part of this patch, if the claim is that an admin who relies on pg_basebackup is relying on essential things pg_basebackup does that have not been enumerated in our documentation yet, I would argue they should be. > with a different API or a different set of tools. That is not a > documentation task. That is a "start from a list of which things > pg_basebackup cannot do that are still simple, or that tools like > pgbackrest cannot do if they're complicated". And then design an API > that's actually safe and easy to use *for that usecase*. That might also be a good thing, but I don't see it as a substitute for documenting the present reality of what the irreducibly essential behaviors of pg_basebackup (or of third-party tools like pgbackrest) are, and why they are so. Regards, -Chap
