Обсуждение: BUG #2495: -i start up option blows pg_ctl program.
The following bug has been logged online: Bug reference: 2495 Logged by: Ermest Email address: whitelaw@netc.pt PostgreSQL version: 8.4.1-1 Operating system: Windows server 2003 Description: -i start up option blows pg_ctl program. Details: When I attempt to configure postgres to allow tcpip connections by adding the -i option at startup, pg_ctl bombs by referencing address 0x0000. The -i is added to the service startup parameters via the Registry. I note also,"tcpip_socket" does not appear in installed postgresql.conf Adding tcpip_socket=true had no effect on the -i bomb out. I have Net 2.0 & IIS installed. I used the postgres-8.4.1-1.zip for my installation. The problem was the same on two different installations on Windows server 2003 - one used for development, one used for production (hence cleaner). Regars
Ermest wrote: > When I attempt to configure postgres to allow tcpip connections by adding > the -i option at startup, pg_ctl bombs by referencing address 0x0000. The > -i is added to the service startup parameters via the Registry. There is indeed a bug in pg_ctl here. We are reporting an error which getopt_long already reported; and furthermore, optarg is not set by that function in case of error. This is the fix: while ((c = getopt_long(argc, argv, "D:l:m:N:o:p:P:sU:wW", long_options, &option_index)) != -1) { switch (c) { ... case default: - write_stderr(_("%s: invalid option %s\n"), progname, optarg); do_advice(); exit(1); > I note also,"tcpip_socketi does not appear in installed postgresql.conf > Adding tcpip_socket=true had no effect on the -i bomb out. No, the tcpip_socket option was removed in 8.0. Use listen_interfaces instead. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes: > There is indeed a bug in pg_ctl here. We are reporting an error which > getopt_long already reported; and furthermore, optarg is not set by that > function in case of error. This is the fix: Good catch, but I'd suggest not just removing the write_stderr but adding a comment in its place: /* getopt_long already issued a suitable error message */ Please commit fix in all relevant branches. regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > There is indeed a bug in pg_ctl here. We are reporting an error which > > getopt_long already reported; and furthermore, optarg is not set by that > > function in case of error. This is the fix: > > Good catch, but I'd suggest not just removing the write_stderr but > adding a comment in its place: > > /* getopt_long already issued a suitable error message */ > > Please commit fix in all relevant branches. I'm working on it. 7.3 does not have our getopt_long, so the first branch to check is 7.4. In my system, on 7.4, contrib/pg_dumplo is linked against the system's getopt_long, not against our version. So the current code is OK -- but if on some platform there is no getopt_long, I suspect our version would be picked, which causes a problem. What should we do about it? One thought is leave it alone -- it's an old branch and no one has ever noticed this problem before. On the other hand, this may possibly be a security issue. On 7.4, pg_ctl was still a shell script, so the exact problem at hand does not exist. On 8.0 there is no pg_dumplo, and pg_ctl is the only program which shows this problem. I'm still investigating other branches. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > In my system, on 7.4, contrib/pg_dumplo is linked against the system's > getopt_long, not against our version. So the current code is OK -- but > if on some platform there is no getopt_long, I suspect our version would > be picked, which causes a problem. What should we do about it? One > thought is leave it alone -- it's an old branch and no one has ever > noticed this problem before. On the other hand, this may possibly be a > security issue. I'm not particularly concerned. AFAICS this is just a cosmetic bug, not a security issue, and for little-used stuff like pg_dumplo I don't think we need go out of our way to fix cosmetic issues in old branches. regards, tom lane