Horton

Thread

  1. pg_basebackup --xlog compatibility break

    Peter Eisentraut <peter_e@gmx.net> — 2012-05-28T20:11:03Z

    In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
takes a required argument.  I think such compatibility breaks should be
avoided, especially in client-side programs.  Now you can't write a
script running pg_basebackup that works with 9.1 and 9.2, if you need to
include the WAL.

I think the behavior of -x/--xlog should be restored to the state of
9.1, and a new option should be added to select between the fetch and
stream methods.  (With a suitable default, this would also increase
usability a bit.)

  2. Re: pg_basebackup --xlog compatibility break

    Magnus Hagander <magnus@hagander.net> — 2012-05-28T20:38:24Z

    On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
> takes a required argument.  I think such compatibility breaks should be
> avoided, especially in client-side programs.  Now you can't write a
> script running pg_basebackup that works with 9.1 and 9.2, if you need to
> include the WAL.
>
> I think the behavior of -x/--xlog should be restored to the state of
> 9.1, and a new option should be added to select between the fetch and
> stream methods.  (With a suitable default, this would also increase
> usability a bit.)

Just to be clear - it's not possible to actually accept -x with an
*optional* parameter, is it? Meaning "-x" would mean the same as "-x
fetch" and therefor become backwards compatible?

IIRC I did try that, and didn't get it to work - but if that's doable,
that seems like the cleanest way?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  3. Re: pg_basebackup --xlog compatibility break

    Fujii Masao <masao.fujii@gmail.com> — 2012-05-28T23:50:36Z

    On Tue, May 29, 2012 at 5:38 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
>> takes a required argument.  I think such compatibility breaks should be
>> avoided, especially in client-side programs.  Now you can't write a
>> script running pg_basebackup that works with 9.1 and 9.2, if you need to
>> include the WAL.
>>
>> I think the behavior of -x/--xlog should be restored to the state of
>> 9.1, and a new option should be added to select between the fetch and
>> stream methods.  (With a suitable default, this would also increase
>> usability a bit.)
>
> Just to be clear - it's not possible to actually accept -x with an
> *optional* parameter, is it? Meaning "-x" would mean the same as "-x
> fetch" and therefor become backwards compatible?
>
> IIRC I did try that, and didn't get it to work - but if that's doable,
> that seems like the cleanest way?

+1 ISTM you need to change getopt_long() to do that.

Regards,

-- 
Fujii Masao

  4. Re: pg_basebackup --xlog compatibility break

    Robert Haas <robertmhaas@gmail.com> — 2012-05-29T17:03:36Z

    On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
>> takes a required argument.  I think such compatibility breaks should be
>> avoided, especially in client-side programs.  Now you can't write a
>> script running pg_basebackup that works with 9.1 and 9.2, if you need to
>> include the WAL.
>>
>> I think the behavior of -x/--xlog should be restored to the state of
>> 9.1, and a new option should be added to select between the fetch and
>> stream methods.  (With a suitable default, this would also increase
>> usability a bit.)
>
> Just to be clear - it's not possible to actually accept -x with an
> *optional* parameter, is it? Meaning "-x" would mean the same as "-x
> fetch" and therefor become backwards compatible?
>
> IIRC I did try that, and didn't get it to work - but if that's doable,
> that seems like the cleanest way?

Aren't you still going to have situations where it's the behavior
changes, if you go this route?

Consider this command line:

$ foo -b bar

Is bar an argument to -b, or an argument to foo?  If -b required or
forbade an argument it would be clear, but if the argument is optional
then it's fuzzy.  Similarly, consider:

$ foo -bar

If -b takes no argument then this means the same thing as "foo -b -a
-r", but and if -b requires an argument then ar is the argument to
foo.  If -b takes an optional argument, then it's ambiguous.

I don't remember the exact behavior of getopt_long(), but I bet if we
go this route we'll find that there are cases where the behavior
changes vs. older releases; they'll just be subtler.  Peter's
suggestion of a separate switch seems better to me for that reason.

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

  5. Re: pg_basebackup --xlog compatibility break

    Fujii Masao <masao.fujii@gmail.com> — 2012-05-29T18:51:52Z

    On Wed, May 30, 2012 at 2:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
>>> takes a required argument.  I think such compatibility breaks should be
>>> avoided, especially in client-side programs.  Now you can't write a
>>> script running pg_basebackup that works with 9.1 and 9.2, if you need to
>>> include the WAL.
>>>
>>> I think the behavior of -x/--xlog should be restored to the state of
>>> 9.1, and a new option should be added to select between the fetch and
>>> stream methods.  (With a suitable default, this would also increase
>>> usability a bit.)
>>
>> Just to be clear - it's not possible to actually accept -x with an
>> *optional* parameter, is it? Meaning "-x" would mean the same as "-x
>> fetch" and therefor become backwards compatible?
>>
>> IIRC I did try that, and didn't get it to work - but if that's doable,
>> that seems like the cleanest way?
>
> Aren't you still going to have situations where it's the behavior
> changes, if you go this route?
>
> Consider this command line:
>
> $ foo -b bar
>
> Is bar an argument to -b, or an argument to foo?  If -b required or
> forbade an argument it would be clear, but if the argument is optional
> then it's fuzzy.  Similarly, consider:
>
> $ foo -bar
>
> If -b takes no argument then this means the same thing as "foo -b -a
> -r", but and if -b requires an argument then ar is the argument to
> foo.  If -b takes an optional argument, then it's ambiguous.
>
> I don't remember the exact behavior of getopt_long(), but I bet if we
> go this route we'll find that there are cases where the behavior
> changes vs. older releases; they'll just be subtler.  Peter's
> suggestion of a separate switch seems better to me for that reason.

You're right. I thought that optional parameter is possible because
I recalled GNU extended getopt(3) supported that. After reading its man,
I found that an argument must be in the same word as the option name
to specify an argument, e.g., -xfetch (not -x fetch). This optional
parameter looks confusing to a user. So I agree to add another parameter.

Regards,

-- 
Fujii Masao

  6. Re: pg_basebackup --xlog compatibility break

    Magnus Hagander <magnus@hagander.net> — 2012-05-29T20:31:20Z

    On Tue, May 29, 2012 at 8:51 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, May 30, 2012 at 2:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>>> In 9.1, the pg_basebackup option --xlog takes no argument.  In 9.2, it
>>>> takes a required argument.  I think such compatibility breaks should be
>>>> avoided, especially in client-side programs.  Now you can't write a
>>>> script running pg_basebackup that works with 9.1 and 9.2, if you need to
>>>> include the WAL.
>>>>
>>>> I think the behavior of -x/--xlog should be restored to the state of
>>>> 9.1, and a new option should be added to select between the fetch and
>>>> stream methods.  (With a suitable default, this would also increase
>>>> usability a bit.)
>>>
>>> Just to be clear - it's not possible to actually accept -x with an
>>> *optional* parameter, is it? Meaning "-x" would mean the same as "-x
>>> fetch" and therefor become backwards compatible?
>>>
>>> IIRC I did try that, and didn't get it to work - but if that's doable,
>>> that seems like the cleanest way?
>>
>> Aren't you still going to have situations where it's the behavior
>> changes, if you go this route?
>>
>> Consider this command line:
>>
>> $ foo -b bar
>>
>> Is bar an argument to -b, or an argument to foo?  If -b required or
>> forbade an argument it would be clear, but if the argument is optional
>> then it's fuzzy.  Similarly, consider:
>>
>> $ foo -bar
>>
>> If -b takes no argument then this means the same thing as "foo -b -a
>> -r", but and if -b requires an argument then ar is the argument to
>> foo.  If -b takes an optional argument, then it's ambiguous.
>>
>> I don't remember the exact behavior of getopt_long(), but I bet if we
>> go this route we'll find that there are cases where the behavior
>> changes vs. older releases; they'll just be subtler.  Peter's
>> suggestion of a separate switch seems better to me for that reason.
>
> You're right. I thought that optional parameter is possible because
> I recalled GNU extended getopt(3) supported that. After reading its man,
> I found that an argument must be in the same word as the option name
> to specify an argument, e.g., -xfetch (not -x fetch). This optional
> parameter looks confusing to a user. So I agree to add another parameter.

Yeah, good arguments all around, i agree too :-) Next question is -
suggestions for naming of said paramter?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  7. Re: pg_basebackup --xlog compatibility break

    Peter Eisentraut <peter_e@gmx.net> — 2012-06-04T12:14:31Z

    On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
> Yeah, good arguments all around, i agree too :-) Next question is -
> suggestions for naming of said paramter?

--xlog-method=something?  And/or -Xsomething, which would automatically
enable -x?

  8. Re: pg_basebackup --xlog compatibility break

    Magnus Hagander <magnus@hagander.net> — 2012-06-10T11:43:42Z

    On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>> Yeah, good arguments all around, i agree too :-) Next question is -
>> suggestions for naming of said paramter?
>
> --xlog-method=something?  And/or -Xsomething, which would automatically
> enable -x?

How's this?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  9. Re: pg_basebackup --xlog compatibility break

    Fujii Masao <masao.fujii@gmail.com> — 2012-06-10T12:48:27Z

    On Sun, Jun 10, 2012 at 8:43 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>>> Yeah, good arguments all around, i agree too :-) Next question is -
>>> suggestions for naming of said paramter?
>>
>> --xlog-method=something?  And/or -Xsomething, which would automatically
>> enable -x?
>
> How's this?

Looks good to me.

Regards,

-- 
Fujii Masao

  10. Re: pg_basebackup --xlog compatibility break

    Magnus Hagander <magnus@hagander.net> — 2012-06-11T13:01:52Z

    On Sun, Jun 10, 2012 at 2:48 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sun, Jun 10, 2012 at 8:43 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>>>> Yeah, good arguments all around, i agree too :-) Next question is -
>>>> suggestions for naming of said paramter?
>>>
>>> --xlog-method=something?  And/or -Xsomething, which would automatically
>>> enable -x?
>>
>> How's this?
>
> Looks good to me.

Ok, thanks. Applied.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  11. Re: pg_basebackup --xlog compatibility break

    Peter Eisentraut <peter_e@gmx.net> — 2012-06-11T21:28:06Z

    On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
> >> Yeah, good arguments all around, i agree too :-) Next question is -
> >> suggestions for naming of said paramter?
> >
> > --xlog-method=something?  And/or -Xsomething, which would automatically
> > enable -x?
> 
> How's this?

I wouldn't make -x and -X exclusive.  The way I understood this is, -x
means include xlog, and -X says how to.

I guess either way of looking at it has its merits.

  12. Re: pg_basebackup --xlog compatibility break

    Magnus Hagander <magnus@hagander.net> — 2012-06-11T21:40:35Z

    On Mon, Jun 11, 2012 at 11:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>> >> Yeah, good arguments all around, i agree too :-) Next question is -
>> >> suggestions for naming of said paramter?
>> >
>> > --xlog-method=something?  And/or -Xsomething, which would automatically
>> > enable -x?
>>
>> How's this?
>
> I wouldn't make -x and -X exclusive.  The way I understood this is, -x
> means include xlog, and -X says how to.
>
> I guess either way of looking at it has its merits.

I guess it's basically two ways of doing the same thing. I'm not
especially attached to either one of them, so if you think the ohter
one is better, I won't object to changing it.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

  13. Re: pg_basebackup --xlog compatibility break

    Thom Brown <thom@linux.com> — 2012-06-12T09:47:24Z

    On 11 June 2012 22:40, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Jun 11, 2012 at 11:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
>>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>>> >> Yeah, good arguments all around, i agree too :-) Next question is -
>>> >> suggestions for naming of said paramter?
>>> >
>>> > --xlog-method=something?  And/or -Xsomething, which would automatically
>>> > enable -x?
>>>
>>> How's this?
>>
>> I wouldn't make -x and -X exclusive.  The way I understood this is, -x
>> means include xlog, and -X says how to.
>>
>> I guess either way of looking at it has its merits.
>
> I guess it's basically two ways of doing the same thing. I'm not
> especially attached to either one of them, so if you think the ohter
> one is better, I won't object to changing it.

+1 for not telling the user off for being explicit by stating both options.

-- 
Thom

  14. Re: pg_basebackup --xlog compatibility break

    Fujii Masao <masao.fujii@gmail.com> — 2012-06-12T17:33:54Z

    On Tue, Jun 12, 2012 at 6:28 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>> >> Yeah, good arguments all around, i agree too :-) Next question is -
>> >> suggestions for naming of said paramter?
>> >
>> > --xlog-method=something?  And/or -Xsomething, which would automatically
>> > enable -x?
>>
>> How's this?
>
> I wouldn't make -x and -X exclusive.  The way I understood this is, -x
> means include xlog, and -X says how to.

And we can specify -X without -x like -Z and -z option of pg_basebackup?
If no, I disagree with you because I don't want to specify two options to
use log streaming method.

Regards,

-- 
Fujii Masao