Re: Switch pg_basebackup to use -X stream instead of -X fetch by default?

On Wed, Aug 27, 2014 at 2:55 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Aug 27, 2014 at 5:16 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Aug 27, 2014 at 6:16 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Tue, Aug 26, 2014 at 10:46 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>>>> On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
>>>>> On 8/26/14 12:40 PM, Magnus Hagander wrote:
>>>>> > I think the first reason is gone now, and the risk/damage of the two
>>>>> > connections is probably smaller than running out of WAL. -x is a good
>>>>> > default for smaller systems, but -X is a safer one for bigger ones. So
>>>>> > I agree that changing the default mode would make sense.
>>>>>
>>>>> I would seriously consider just removing one of the modes.  Having two
>>>>> modes is complex enough, and then having different defaults in different
>>>>> versions, and fuzzy recommendations like, it's better for "smaller
>>>>> systems", it's quite confusing.
>>>>
>>>> Happy with removing the option and just accepting -X for backward
>>>> compat.
>>>
>>> Works for me - this is really the cleaner way of doing it...
>>
>> We cannot use -X stream with tar output format mode. So I'm afraid that
>> removing -X fetch would make people using tar output format feel disappointed.
>> Or we should make -X stream work with tar mode.
>
> Ah, yes, I've actually had that on my TODO for some time.
>
> I think the easy way of doing that is to just create an xlog.tar file.
> Since we already create "base.tar" and possibly n*<tablespace.tar>,
> adding one more file shouldn't be a big problem, and would make such
> an implementation much easier. Would be trivial to do .tar.gz for it
> as well, just like for the others.

Still, that seems like a pretty good reason not to rip the old mode
out completely.  Actually, I'd favor that anyway: changing the default
in one release and removing the deprecated feature in a later release
usually provides a smoother upgrade path.  But if there are features
that aren't even present in the newer mode yet, that's an even better
reason.

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