Greetings,
* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Fri, Jan 14, 2022 at 11:31 AM Stephen Frost <sfrost@snowman.net> 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.
>
> For all my suggestions of "use third-party where possible" I do think that
> we should have, probably as part of pg_basebackup, a mode that performs a
> filesystem copy of WAL to an archive location and verifies that the archive
> is valid otherwise it write to the PostgreSQL log that there was a
> problem. pg_basebackup should either be able to install that command (with
> maybe some CLI prompts for settings or something) using ALTER SYSTEM. Our
> documentation can then demonstrate the example usage of the archive_command
> parameters as being a generic form of that command.
We already have pg_receivewal, which is part of pg_basebackup, and is
able to use a slot and such. I'm not sure that making pg_basebackup
somehow also work as an archive command makes much sense- it's really
intended to be a tool that's used remotely and that isn't going to work
when being called out of archive_command.
That is, if I'm on system B and doing pg_basebackup against system A,
all of which happens using the PG replication protocol, how would
pg_basebackup called out of archive_command be able to get the WAL over
to system B..?
Thanks,
Stephen
