On Thu, Jan 20, 2011 at 16:45, Bruce Momjian <br...@momjian.us> wrote: > 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.
Yeah, we're certianly not taking those *away*. > Do we envision pg_basebackup as something we will enahance, and if so, > should we consider a generic name? Well, it's certainly going to be enhanced. I think there are two main uses for it - backups, and setting up replication slaves. I can't see it expanding beyond those, really. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
