Re: pg_basebackup for streaming base backups - Mailing list pgsql-hackers

On Thu, Jan 20, 2011 at 10:15 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Thu, Jan 20, 2011 at 10:01 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> > Magnus Hagander wrote:
>> >> On Mon, Jan 17, 2011 at 16:27, Simon Riggs <simon@2ndquadrant.com> wrote:
>> >> > On Mon, 2011-01-17 at 16:20 +0100, Magnus Hagander wrote:
>> >> >> On Mon, Jan 17, 2011 at 16:18, Robert Haas <robertmhaas@gmail.com> wrote:
>> >> >> > On Mon, Jan 17, 2011 at 8:55 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> >> >> >> Hmm. I don't like those names at all :(
>> >> >> >
>> >> >> > I agree. ?I don't think your original names are bad, as long as
>> >> >> > they're well-documented. ?I sympathize with Simon's desire to make it
>> >> >> > clear that these use the replication framework, but I really don't
>> >> >> > want the command names to be that long.
>> >> >>
>> >> >> Actually, after some IM chats, I think pg_streamrecv should be
>> >> >> renamed, probably to pg_walstream (or pg_logstream, but pg_walstream
>> >> >> is a lot more specific than that)
>> >> >
>> >> > pg_stream_log
>> >> > pg_stream_backup
>> >>
>> >> Those seem better.
>> >>
>> >> Tom, would those solve your concerns about it being clear which side
>> >> they are on? Or do you think you'd still risk reading them as the
>> >> sending side?
>> >
>> > It seems pg_create_backup would be the most natural because we already
>> > have pg_start_backup and pg_stop_backup.
>>
>> Uh, wow.  That's really mixing apples and oranges.
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company