Обсуждение: Call for objections: deprecate postmaster -o switch?
We had a discussion in late September about deprecating the postmaster's -o switch in the 7.2 documentation, with an eye to removing it in 7.3: see thread starting athttp://fts.postgresql.org/db/mw/msg.html?mid=1036935 It wasn't entirely clear to me whether everyone had agreed to the idea of marking -o deprecated in the 7.2 docs, so here's your chance to object if you think it's a bad idea... regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is there no overlap in the postgres/postmaster flags?
Yeah, there is. That's why we need to give people warning of what
we intend to break. See prior thread.
regards, tom lane
> We had a discussion in late September about deprecating the postmaster's > -o switch in the 7.2 documentation, with an eye to removing it in 7.3: > see thread starting at > http://fts.postgresql.org/db/mw/msg.html?mid=1036935 > > It wasn't entirely clear to me whether everyone had agreed to the idea > of marking -o deprecated in the 7.2 docs, so here's your chance to > object if you think it's a bad idea... Is there no overlap in the postgres/postmaster flags? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Is there no overlap in the postgres/postmaster flags? > > Yeah, there is. That's why we need to give people warning of what > we intend to break. See prior thread. So we just mention it is going away, but there are duplicates so they can't start removing -o yet? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, now I remember. Do we support long command-line options on all > > platforms? I don't think so. > > GUC variable assignment works on all platforms. OK, but when we recommend, we had better tell them to start using GUC and not long command-line options _unless_ long options are supported on their platform. Without that, there will be confusion. Of course, now that we are recommending GUC, all the flags become useless. Kind of a circular arguement here. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, but when we recommend, we had better tell them to start using GUC
> and not long command-line options _unless_ long options are supported on
> their platform. Without that, there will be confusion.
This is entirely irrelevant, because the postmaster and backend don't
have any long options (except GUC variables which work anyway).
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > So we just mention it is going away, but there are duplicates so they > > can't start removing -o yet? > > Well, we'd have to give a table of recommended translations, eg > > -o '-S n' => --sort-mem=n > > The translations all exist already, but we've got to start telling > people to quit using the old switches, or we'll never be able to clean > them up. Yes, now I remember. Do we support long command-line options on all platforms? I don't think so. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So we just mention it is going away, but there are duplicates so they
> can't start removing -o yet?
Well, we'd have to give a table of recommended translations, eg
-o '-S n' => --sort-mem=n
The translations all exist already, but we've got to start telling
people to quit using the old switches, or we'll never be able to clean
them up.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, now I remember. Do we support long command-line options on all
> platforms? I don't think so.
GUC variable assignment works on all platforms.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > OK, but when we recommend, we had better tell them to start using GUC > > and not long command-line options _unless_ long options are supported on > > their platform. Without that, there will be confusion. > > This is entirely irrelevant, because the postmaster and backend don't > have any long options (except GUC variables which work anyway). Oh, I see. We don't use long options for postmaster/postgres, just the -c option to set a GUC value. Got it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > So we just mention it is going away, but there are duplicates so they > > can't start removing -o yet? > > Well, we'd have to give a table of recommended translations, eg > > -o '-S n' => --sort-mem=n This is the part that threw me off. I see in the postmaster docs under -c: On some systems it is also possible to equivalently use GNU-style long options in the form --name=value. so we would have to recommend '-c sort-mem=n.' -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> This is the part that threw me off. I see in the postmaster docs under
> -c:
> On some systems it is also possible to equivalently
> use GNU-style long options in the form
> --name=value.
> so we would have to recommend '-c sort-mem=n.'
--sort-mem works, period. Read the code.
That part of the docs is in error, evidently.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > This is the part that threw me off. I see in the postmaster docs under > > -c: > > On some systems it is also possible to equivalently > > use GNU-style long options in the form > > --name=value. > > > so we would have to recommend '-c sort-mem=n.' > > --sort-mem works, period. Read the code. > > That part of the docs is in error, evidently. Docs updated. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > This is the part that threw me off. I see in the postmaster docs under > > > -c: > > > On some systems it is also possible to equivalently > > > use GNU-style long options in the form > > > --name=value. > > > > > so we would have to recommend '-c sort-mem=n.' > > > > --sort-mem works, period. Read the code. > > > > That part of the docs is in error, evidently. > > Docs updated. Please change it back. -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes: > --sort-mem works, period. Read the code. > > That part of the docs is in error, evidently. No it's not, unfortunately. BSD versions of getopt, including the one we ship as replacement, have a bug that considers any argument that starts with '--' to be equivalent with '--' (which means end of options). -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes: > We had a discussion in late September about deprecating the postmaster's > -o switch in the 7.2 documentation, with an eye to removing it in 7.3: I'm not sure this notice would be utterly helpful since we have no concrete plans for any of the other options that need to be merged. The best we can say right now is that "all 'postgres' options might change or disappear soon". -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> No it's not, unfortunately. BSD versions of getopt, including the one we
> ship as replacement, have a bug that considers any argument that starts
> with '--' to be equivalent with '--' (which means end of options).
Ugh. Nonetheless, that doesn't equate to "you need GNU getopt to use
this". Can we be more specific about whether it works or not?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> We had a discussion in late September about deprecating the postmaster's
>> -o switch in the 7.2 documentation, with an eye to removing it in 7.3:
> I'm not sure this notice would be utterly helpful since we have no
> concrete plans for any of the other options that need to be merged.
I was just planning to recommend not using -o, in favor of the already-
existing alternatives (-o -F => -F, -o -S n => --sort-mem=n, etc).
regards, tom lane
> Peter Eisentraut <peter_e@gmx.net> writes:
> > No it's not, unfortunately. BSD versions of getopt, including the one we
> > ship as replacement, have a bug that considers any argument that starts
> > with '--' to be equivalent with '--' (which means end of options).
>
> Ugh. Nonetheless, that doesn't equate to "you need GNU getopt to use
> this". Can we be more specific about whether it works or not?
OK, I just checked BSD/OS, and see in the docs:
The getopt() function returns -1 when the argument list is exhausted, or a non-recognized option is encountered. The
interpretationof options in the argument list may be cancelled by the option `--' (double dash) which causes getopt()
tosignal the end of argument processing and returns -1. When all options have been processed (i.e., up to the first
non-optionargument), getopt() returns -1.
However, I also see:
Option arguments are allowed to begin with ``-''; this is reasonable but reduces the amount of error checking
possible.
I see in postmaster.c:
while ((opt = getopt(argc, argv, "A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) !=
^
And I started the postmaster using:
./bin/postmaster -B 2000 -i $DEBUG --sort-mem=60
so while the documentation says "--" ends arguments, it appears if you
specify "-" to getopt, it will honor it and not end the argument list.
Because this is identical on BSD/OS and FreeBSD, I assume all the BSD's
are the same. Peter, was there a specific failure of "--" options that
you remember?
I will be glad to put the docs back to warning about "--" options if is
indeed true, or perhaps we can be more specific.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> And I started the postmaster using:
> ./bin/postmaster -B 2000 -i $DEBUG --sort-mem=60
But
(a) did the sort_mem setting "take"?
(b) can you put more than one variable setting in there and have
them all take?
I tried
postmaster ... --enable_hashjoin=false --enable-mergejoin=false
and then verified
regression=# show enable_hashjoin;
NOTICE: enable_hashjoin is off
SHOW VARIABLE
regression=# show enable_mergejoin;
NOTICE: enable_mergejoin is off
SHOW VARIABLE
so it works okay on HPUX.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> No it's not, unfortunately. BSD versions of getopt, including the one we
> ship as replacement, have a bug that considers any argument that starts
> with '--' to be equivalent with '--' (which means end of options).
I believe we could trivially fix our substitute version: at line 74 of
src/utils/getopt.c,
if (place[1] && *++place == '-')
should be
if (place[1] && *++place == '-' && place[1] == '\0')
It might still not work on older BSDen, but there's no reason it
shouldn't work on platforms where we use our own code.
A slightly more aggressive answer would be to use our own code always,
or to test for brokenness of the system getopt in configure and use our
own code if so.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> (a) did the sort_mem setting "take"?
> Sure did. I tried a sort value too low and it complained.
Okay, so the original bug is fixed on your version of BSD. (Which
is what, again?)
I looked a bit at configure and realized that we have no configure
test that causes src/utils/getopt.c to be selected. Apparently,
the *only* platform where src/utils/getopt.c is used is native WIN32,
so the "--foo" bug in it is irrelevant to the postmaster anyway.
But I'm still inclined to fix the bug.
It would be good to try to get a reading on whether there are any
current BSD distros that still have the getopt bug. But what I'm
inclined to do is note under the description of "--foo" that there
are a few older platforms where it won't work and you have to use -c,
rather than writing the docs on the assumption that -c is what most
people need to use.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > And I started the postmaster using: > > ./bin/postmaster -B 2000 -i $DEBUG --sort-mem=60 > > But > > (a) did the sort_mem setting "take"? > Sure did. I tried a sort value too low and it complained. > (b) can you put more than one variable setting in there and have > them all take? Yes. In your test: ./bin/postmaster -B 2000 -i $DEBUG --enable_hashjoin=false --enable-mergejoin=false I get from a restarted postmaster: test=> show enable_hashjoin;NOTICE: enable_hashjoin is offSHOW VARIABLEtest=> show enable_mergejoin;NOTICE: enable_mergejoinis offSHOW VARIABLE -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> (a) did the sort_mem setting "take"?
>
> > Sure did. I tried a sort value too low and it complained.
>
> Okay, so the original bug is fixed on your version of BSD. (Which
> is what, again?)
I am using BSD/OS 4.2. Because the other BSD's mention "--" as
supported, I assume they are OK too. Perhaps our BSD getopt() is an
older version.
In digging, I see this comment in the getopt.c BSD/OS source:
* Pick up from where we left off, or start anew if necessary. * When starting on a new argument, check for "-"
and"--". * Compatibility exception: a lone "-" is considered an option * if the option string includes "-".
I also see new code handling "--" However, I don't see this message or
code in the NetBSD getopt.c source. I do see this NetBSD commit message
from January, 1999:
1003.2-92 specifies the string "--" to be recognized as the option list delimiter as opposed to any string merely
beginningwith '-''-'; change to match the standard. From Simon J. Gerraty <sjg@quick.com.au> in PR lib/6762.
so it looks like each BSD fixed it in their own way. Looking at
FreeBSD, I don't see any commit message describing the fix. If I
compare the NetBSD, FreeBSD, and our own getopt sources, I see this
addition in NetBSD which appears to be the fix mentioned in the NetBSD
commit message above:
if (place[1] && *++place == '-' /* found "--" */ --> && place[1] == '\0') {
And to confirm that, I see at:
http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/lib/libc/stdlib/getopt.c.diff?r1=1.12&r2=1.13
this exact change:
- if (place[1] && *++place == '-') { /* found "--" */
+ if (place[1] && *++place == '-' /* found "--" */
+ && place[1] == '\0') {
So, every BSD has fixed it themselves, and we should probably apply the
above fix to our own copy, or just grab NetBSD's. Also, because FreeBSD
doesn't have this fix, we should ask them to add it, and perhaps add a
configure test to see if getopt "--" works on this platform.
> I looked a bit at configure and realized that we have no configure
> test that causes src/utils/getopt.c to be selected. Apparently,
> the *only* platform where src/utils/getopt.c is used is native WIN32,
> so the "--foo" bug in it is irrelevant to the postmaster anyway.
> But I'm still inclined to fix the bug.
>
> It would be good to try to get a reading on whether there are any
> current BSD distros that still have the getopt bug. But what I'm
> inclined to do is note under the description of "--foo" that there
> are a few older platforms where it won't work and you have to use -c,
> rather than writing the docs on the assumption that -c is what most
> people need to use.
Agreed, though we may want to hard-code using our own, fixed getopt()
for FreeBSD.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> (a) did the sort_mem setting "take"?
>
> > Sure did. I tried a sort value too low and it complained.
>
> Okay, so the original bug is fixed on your version of BSD. (Which
> is what, again?)
I just ran a test on postgresql.org. There is no SysV support so I
can't initdb, but I see:
$ postmaster -D x postmaster does not find the database system. Expected to find it in the PGDATA directory "x",
but unable to open file "x/global/pg_control": No such file or directory
$ postmaster -c sort-mem=30 -D x postmaster does not find the database system. Expected to find it in the PGDATA
directory"x", but unable to open file "x/global/pg_control": No such file or directory
$ postmaster --sort-mem=30 -D x postmaster: invalid argument -- -D Try 'postmaster --help' for more information.
Notice that the last attempt has the -D after a "--" options, rather
than after a "-c" options. Sure looks like FreeBSD doesn't have the
fix.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Tom Lane writes: > Ugh. Nonetheless, that doesn't equate to "you need GNU getopt to use > this". ... which is not what it used to say either. > Can we be more specific about whether it works or not? I reported the bug on 2000-11-06 to this list and added the -c option briefly afterwards. The bug caused initdb to fail on whatever FreeBSD version postgresql.org was running at the time. I agree that we could alter the "works on some platforms" to "might not work on some platforms". -- Peter Eisentraut peter_e@gmx.net
> Tom Lane writes: > > > Ugh. Nonetheless, that doesn't equate to "you need GNU getopt to use > > this". > > ... which is not what it used to say either. > > > Can we be more specific about whether it works or not? > > I reported the bug on 2000-11-06 to this list and added the -c option > briefly afterwards. The bug caused initdb to fail on whatever FreeBSD > version postgresql.org was running at the time. > > I agree that we could alter the "works on some platforms" to "might not > work on some platforms". I just checked and OpenBSD doesn't have the fix either. Questions: 1) should we patch our getopt.c with that single-line fix? 2) should we force our own getopt on FreeBSD and OpenBSD for 7.2? 3) how should we update the docs for this? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I just checked and OpenBSD doesn't have the fix either. Questions: > > > 1) should we patch our getopt.c with that single-line fix? > > Fixing our getopt seems like a no-brainer: yes. Done. > > 2) should we force our own getopt on FreeBSD and OpenBSD for 7.2? > > This is more debatable. If it were earlier in the beta cycle I'd say > yes, but at this point I don't think we should take any risks for what > is after all a cosmetic issue. Put it on TODO for 7.3, instead. Added to TODO: * Use our own getopt() for FreeBSD/OpenBSD to allow --xxx flags (Bruce) > > 3) how should we update the docs for this? > > "--name=val may not work on some platforms, if not use -c name=val". OK, I will add that it doesn't work on FreeBSD and OpenBSD, specifically. This way, if it doesn't work on other platforms, hopefully we will hear about it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I just checked and OpenBSD doesn't have the fix either. Questions:
> 1) should we patch our getopt.c with that single-line fix?
Fixing our getopt seems like a no-brainer: yes.
> 2) should we force our own getopt on FreeBSD and OpenBSD for 7.2?
This is more debatable. If it were earlier in the beta cycle I'd say
yes, but at this point I don't think we should take any risks for what
is after all a cosmetic issue. Put it on TODO for 7.3, instead.
> 3) how should we update the docs for this?
"--name=val may not work on some platforms, if not use -c name=val".
regards, tom lane
> > > 3) how should we update the docs for this? > > > > "--name=val may not work on some platforms, if not use -c name=val". > > OK, I will add that it doesn't work on FreeBSD and OpenBSD, > specifically. This way, if it doesn't work on other platforms, > hopefully we will hear about it. OK, new text is: The <option>--</> option will not work on FreeBSD or OpenBSD.Use <option>-c</> instead. This should be fixed in<productname>PostgreSQL</productname>7.3. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026