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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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: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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend