Обсуждение: pg_basebackup --xlog compatibility break
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.)
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/
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
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
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
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/
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?
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/
Вложения
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
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/
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.
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/
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
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