Greetings, * Ron (ronljohnso...@gmail.com) wrote: > On 1/14/22 12:31 PM, Stephen Frost wrote: > >* Issa Gorissen (issa-goris...@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
signature.asc
Description: PGP signature
