Greetings,
* Ron (ronljohnsonjr@gmail.com) wrote:
> On 1/14/22 12:31 PM, Stephen Frost wrote:
> >* Issa Gorissen (issa-gorissen@usa.net) wrote:
> >>Thx a lot. I thought about it but was not so sure about having a complex
> >>script (compared to the very simple version when using the exclusive backup
> >>- but this this is deprecated...).
> >>
> >>I will test your option with the simpler version and post it back to it can
> >>maybe land in PostgreSQL documentation.
> >The PG docs show how the command works and that's it. The commands
> >in the docs aren't intended to be actually used in production
> >environments. Writing a full solution involves having a good
> >understanding of the PG code and how WAL archiving, backups, et al, are
> >done. If you're not familiar with this portion of the PG code base, I'd
> >strongly suggest you look at using solutions written and maintained by
> >folks who are.
>
> Needing to read the PG source code to write a workable PITR recovery
> solution is a serious flaw in PG documentation (and why I use PgBackRest).
I disagree that it's a flaw in the documentation- it's an unfortunate
reality of the current core code. We shouldn't be trying to provide
documentation around how to write a tool like pgbackrest, we should,
instead, have a tool like pgbackrest in core with its own documentation,
as most other RDBMS's do.
> The documentation of two other RDBMSs that I've worked with (Rdb/VMS and SQL
> Server) are perfectly clear on how to do such backups and restores with
> relatively small amounts of scripting.
... using tools which are purpose built to the task, no?
Thanks,
Stephen
