Robert Haas wrote:
> > I read the description as:
> >
> > + ? ?You can also use the <xref linkend="app-pgbasebackup"> tool to take
> > + ? ?the backup, instead of manually copying the files. This tool will take
> > + ? ?care of the <function>pg_start_backup()</>, copy and
> > + ? ?<function>pg_stop_backup()</> steps automatically, and transfers the
> > + ? ?backup over a regular <productname>PostgreSQL</productname> connection
> > + ? ?using the replication protocol, instead of requiring filesystem level
> > + ? ?access.
> >
> > so I thought, well it does pg_start_backup and pg_stop_backup, and also
> > creates the data directory.
>
> Yeah, but pg_start_backup() and pg_stop_backup() are server functions,
> and this is an application.
>
> Also, it won't actually work unless the server has replication
> configured (wal_level!=minimal, max_wal_senders>0, and possibly some
> setting for wal_keep_segments), which has been the main point of the
> naming discussion thus far. Now, you know what would be REALLY cool?
> Making this work without any special advance configuration. Like if
> we somehow figured out a way to make max_wal_senders unnecessary, and
> a way to change wal_level without bouncing the server, so that we
> could temporarily boost the WAL level from minimal to archive if
> someone's running a backup.
>
> That, however, is not going to happen for 9.1... but it would be
> *really* cool.
Well, when we originally implemented PITR, we could have found a way to
avoid using SQL commands to start/stop backup, but we envisioned that we
would want to hook things on to those commands so we created a stable
API that we could improve, and we have.
Do we envision pg_basebackup as something we will enahance, and if so,
should we consider a generic name?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
