> > I've seen both these messages after each other when -i is not 
> > specified. Been meaning to adress the issue of it not failing 
> > gracefully without -i on win32.
> >
> > Anyway. It seems the postmaster goes down while a child process is 
> > still going up (stats collector, I guess) or something along that 
> > line. This way the child can't attach to shared memory, and 
> there you 
> > go.
> >
> > If you add PID information to the log, you will notice that the 
> > messages are from two different processes.
> >
> 
> Is there a case for forcing -i and ignoring the GUC setting 
> on Windows? Since we can't do Unix domain sockets there it 
> would seem to make sense.

Yeah, that could be done. I was more into doing a generic fix that would
fail gracefully in any case when the server is not listening on anything
(no Unix, no TCPIP) and error out then. 

Are there any other platforms which don't have unix sockets? If not,
then that thought is not valid, and we shuold just force it on win32. If
not, how do they handle starting of the postmaster without -i today? And
do we want the same behaviour there? 

Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
way we don't suddenly open up to external connections without the user
asking for it.

//Magnus

Fri, 5 Mar 2004 13:52:40 +0100
"Magnus Hagander" <mha@sollentuna.net>
Re: [HACKERS] Another crack at doing a Win32 build under MINGW
Magnus Hagander said:
>> > I've seen both these messages after each other when -i is not
>> > specified. Been meaning to adress the issue of it not failing
>> > gracefully without -i on win32.
>> >
>> > Anyway. It seems the postmaster goes down while a child process is
>> > still going up (stats collector, I guess) or something along that
>> > line. This way the child can't attach to shared memory, and
>> there you
>> > go.
>> >
>> > If you add PID information to the log, you will notice that the
>> > messages are from two different processes.
>> >
>>
>> Is there a case for forcing -i and ignoring the GUC setting
>> on Windows? Since we can't do Unix domain sockets there it
>> would seem to make sense.
>
> Yeah, that could be done. I was more into doing a generic fix that
> would fail gracefully in any case when the server is not listening on
> anything (no Unix, no TCPIP) and error out then.
>
> Are there any other platforms which don't have unix sockets? If not,
> then that thought is not valid, and we shuold just force it on win32.
> If not, how do they handle starting of the postmaster without -i today?
> And do we want the same behaviour there?
>
> Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
> way we don't suddenly open up to external connections without the user
> asking for it.
>

Hmm. That also raises the question of what we should do if virtual_host is
set.

[thinks some more ...]

cheers

andrew



Fri, 5 Mar 2004 09:10:56 -0500 (EST)
"Andrew Dunstan" <andrew@dunslane.net>
Re: [HACKERS] Another crack at doing a Win32 build under MINGW
I wrote:

>Magnus Hagander said:
>  
>
>>>Is there a case for forcing -i and ignoring the GUC setting
>>>on Windows? Since we can't do Unix domain sockets there it
>>>would seem to make sense.
>>>      
>>>
>>Yeah, that could be done. I was more into doing a generic fix that
>>would fail gracefully in any case when the server is not listening on
>>anything (no Unix, no TCPIP) and error out then.
>>
>>Are there any other platforms which don't have unix sockets? If not,
>>then that thought is not valid, and we shuold just force it on win32.
>>If not, how do they handle starting of the postmaster without -i today?
>>And do we want the same behaviour there?
>>
>>Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
>>way we don't suddenly open up to external connections without the user
>>asking for it.
>>
>>    
>>
>
>Hmm. That also raises the question of what we should do if virtual_host is
>set.
>
>[thinks some more ...]
>
>  
>
 .....

How does this sound?

. if -i/tcpip_socket is not set, then bind to localhost
. if -i/tcpip_socket is set, and virtual_host is not set, behave as now 
(i.e. bind to all addresses)
. if  -i/tcpip_socket is set, and virtual_host is set, bind to all but 
immediately close connections where the local address is not either 
localhost or the virtual_host.

That seems to me to get as close as reasonably possible to the Unix 
behaviour. I don't think that always allowing localhost connections on 
Windows is a big security risk.

Also, what is the default connection mode of psql? It should probably be 
equivalent to "-h localhost", shouldn't it?

I haven't thought through what might be the IP4/IP6 implications.

cheers

andrew

Fri, 05 Mar 2004 09:56:29 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] Another crack at doing a Win32
"Magnus Hagander" <mha@sollentuna.net> writes:
> Are there any other platforms which don't have unix sockets?

There are a couple, although I think those ports may be moribund
(if anyone still cares about BeOS, they haven't mentioned it lately).

> Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
> way we don't suddenly open up to external connections without the user
> asking for it.

That seems like a reasonable compromise.

			regards, tom lane

Fri, 05 Mar 2004 10:14:50 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Another crack at doing a Win32 build under MINGW 
Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Are there any other platforms which don't have unix sockets?
> 
> There are a couple, although I think those ports may be moribund
> (if anyone still cares about BeOS, they haven't mentioned it lately).
> 
> > Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
> > way we don't suddenly open up to external connections without the user
> > asking for it.
> 
> That seems like a reasonable compromise.

Agreed, but how do we do that.  pg_hba.conf already only listens on
127.0.0.1.  Do we ignore non-local IPs in that file until they use -i?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 5 Mar 2004 10:31:03 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Another crack at doing a Win32 build
Bruce Momjian wrote:

>Tom Lane wrote:
>  
>
>>"Magnus Hagander" <mha@sollentuna.net> writes:
>>    
>>
>>>Are there any other platforms which don't have unix sockets?
>>>      
>>>
>>There are a couple, although I think those ports may be moribund
>>(if anyone still cares about BeOS, they haven't mentioned it lately).
>>
>>    
>>
>>>Perhaps we should force it to open a tcp socket on 127.0.0.1 only? That
>>>way we don't suddenly open up to external connections without the user
>>>asking for it.
>>>      
>>>
>>That seems like a reasonable compromise.
>>    
>>
>
>Agreed, but how do we do that.  pg_hba.conf already only listens on
>127.0.0.1.  Do we ignore non-local IPs in that file until they use -i?
>
>  
>
Those are remote addresses, not local addresses. pg_hba.conf doesn't say 
anything at all about the listening address. The errors that have been 
reported would have passed the default pg_hba.conf filters - the problem 
as I understand it was that there was no listener on the localhost 
interface.

It is true, though,. that you can't (or shouldn't) be able to connect to 
localhost except from localhost.

cheers

andrew

Fri, 05 Mar 2004 10:41:12 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] Another crack at doing a Win32
Andrew Dunstan wrote:
> How does this sound?
> 
> . if -i/tcpip_socket is not set, then bind to localhost
> . if -i/tcpip_socket is set, and virtual_host is not set, behave as now 
> (i.e. bind to all addresses)
> . if  -i/tcpip_socket is set, and virtual_host is set, bind to all but 
> immediately close connections where the local address is not either 
> localhost or the virtual_host.
> 
> That seems to me to get as close as reasonably possible to the Unix 
> behaviour. I don't think that always allowing localhost connections on 
> Windows is a big security risk.
> 
> Also, what is the default connection mode of psql? It should probably be 
> equivalent to "-h localhost", shouldn't it?

Now that is something I had not thought of.  Seems we can assume a Win32
psql can never use unix domain sockets, so defaulting that to localhost
is a good solution too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 5 Mar 2004 11:13:40 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Another crack at doing a Win32
> Andrew Dunstan wrote:
>> That seems to me to get as close as reasonably possible to the Unix 
>> behaviour. I don't think that always allowing localhost connections on 
>> Windows is a big security risk.

Is it a big security risk anywhere?  Perhaps there is a case to be made
that on all platforms, "-i" should enable or disable only nonlocal
connections.  Without -i we'd only allow binding to loopback ports
(either IP4 or IP6).

Aside from keeping the Windows and Unix behaviors similar, this would be
of some positive benefit for people who use TCP-only clients.  They'd
not have to remember to set -i anymore, unless they want remote access.

In response to Andrew's table, here's what I'm visualizing:

* No -i: bind only to loopback addresses (both IP4 and IP6 if available).
* With -i, but not virtual_host: bind to all available addresses.
* With -i and virtual_host: bind to specified address(es) only.

(Note this is orthogonal to pg_hba.conf checks; we are talking about
what socket addresses the postmaster listens on.)

I don't have a strong feeling about the case of virtual_host without -i.
The above says to ignore virtual_host, but maybe we should instead
ignore the lack of -i and do what virtual_host says.

			regards, tom lane

Fri, 05 Mar 2004 11:58:50 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Another crack at doing a Win32 
Tom Lane wrote:

>Perhaps there is a case to be made
>that on all platforms, "-i" should enable or disable only nonlocal
>connections.  Without -i we'd only allow binding to loopback ports
>(either IP4 or IP6).
>
>Aside from keeping the Windows and Unix behaviors similar, this would be
>of some positive benefit for people who use TCP-only clients.  They'd
>not have to remember to set -i anymore, unless they want remote access.
>  
>

I've been caught by this more than once, because I use local JDBC 
clients, so now the first thing I do after initdb is to set tcpip_socket 
to true.

>In response to Andrew's table, here's what I'm visualizing:
>
>* No -i: bind only to loopback addresses (both IP4 and IP6 if available).
>  
>

OK.

>* With -i, but not virtual_host: bind to all available addresses.
>  
>

OK.

>* With -i and virtual_host: bind to specified address(es) only.
>  
>

Can you bind one socket to more than one address? My understanding is 
that it's all (IN_ADDR_ANY or in6_addr_any) or one. In that case with 
this proposal we'd have to force all the communications through that 
interface on Windows. Or would we use multiple sockets (in which case 
there is probably a good case for allowing multiple addresses in 
virtual_host)?

...  (haven't toured this part of the code before) ....

I see what looks like an array of listen sockets, so multiple sockets 
seems the way to go.

>
>I don't have a strong feeling about the case of virtual_host without -i.
>The above says to ignore virtual_host, but maybe we should instead
>ignore the lack of -i and do what virtual_host says.
>
>  
>

I have no strong feelings either.

cheers

andrew

Fri, 05 Mar 2004 12:38:13 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] Another crack at doing a Win32
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> * With -i and virtual_host: bind to specified address(es) only.

> Can you bind one socket to more than one address?

Nope.  That's why we have provisions to listen on more than one socket.
I think that was implemented for virtual_host, but it'd be necessary
anyway for dual IPv4/IPv6 support.

			regards, tom lane

Fri, 05 Mar 2004 16:48:58 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Another crack at doing a Win32 
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Tom Lane wrote:
>>    
>>
>>>* With -i and virtual_host: bind to specified address(es) only.
>>>      
>>>
>
>  
>
>>Can you bind one socket to more than one address?
>>    
>>
>
>Nope.  That's why we have provisions to listen on more than one socket.
>I think that was implemented for virtual_host, but it'd be necessary
>anyway for dual IPv4/IPv6 support.
>
>  
>

I should have read the code instead of the docs, which only talk about 
one address under virtual_host, not a space separated list of them:

virtual_host (string)

    Specifies the host name or IP address on which the server is to
    listen for connections from client applications. The default is to
    listen on all configured addresses (including localhost).



cheers

andrew

Fri, 05 Mar 2004 17:06:16 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: [HACKERS] Another crack at doing a Win32
Andrew Dunstan <andrew@dunslane.net> writes:
> I should have read the code instead of the docs, which only talk about 
> one address under virtual_host, not a space separated list of them:

That's pretty bogus.  I've committed improved wording.

			regards, tom lane

Fri, 05 Mar 2004 18:56:33 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Another crack at doing a Win32 

[removing to hackers as it is of general interest]

Tom Lane wrote:

>>Andrew Dunstan wrote:
>>    
>>
>>>That seems to me to get as close as reasonably possible to the Unix 
>>>behaviour. I don't think that always allowing localhost connections on 
>>>Windows is a big security risk.
>>>      
>>>
>
>Is it a big security risk anywhere?  Perhaps there is a case to be made
>that on all platforms, "-i" should enable or disable only nonlocal
>connections.  Without -i we'd only allow binding to loopback ports
>(either IP4 or IP6).
>
>Aside from keeping the Windows and Unix behaviors similar, this would be
>of some positive benefit for people who use TCP-only clients.  They'd
>not have to remember to set -i anymore, unless they want remote access.
>
>In response to Andrew's table, here's what I'm visualizing:
>
>* No -i: bind only to loopback addresses (both IP4 and IP6 if available).
>* With -i, but not virtual_host: bind to all available addresses.
>* With -i and virtual_host: bind to specified address(es) only.
>
>(Note this is orthogonal to pg_hba.conf checks; we are talking about
>what socket addresses the postmaster listens on.)
>
>I don't have a strong feeling about the case of virtual_host without -i.
>The above says to ignore virtual_host, but maybe we should instead
>ignore the lack of -i and do what virtual_host says.
>  
>

This slipped off my radar. I have just spent a little while thinking 
about it. How about this: we replace tcpip_socket and virtual_host with 
a new var called listen_addresses, which can have values of "local", 
"all", or a list of addresses? The default would be "local" and -i would 
correspond to "all".

Yes, I know it's not backwards compatible, but we just went through that 
argument with log_line_prefix ;-)

Actually, if we wanted to go the whole hog with virtual hosting we'd 
allow per-address port specification, like apache does, but maybe that's 
something to be left for another day ;-)

cheers

andrew





Sun, 14 Mar 2004 08:57:45 -0500
Andrew Dunstan <andrew@dunslane.net>
listening addresses
Andrew Dunstan <andrew@dunslane.net> writes:
> This slipped off my radar. I have just spent a little while thinking 
> about it. How about this: we replace tcpip_socket and virtual_host with 
> a new var called listen_addresses, which can have values of "local", 
> "all", or a list of addresses? The default would be "local" and -i would 
> correspond to "all".

No objection here.  You could also allow "none" (or maybe that falls out
of the list case by writing an empty list), with the understanding that
"none" is a useless setting on Windows or any other platform that
doesn't support Unix sockets.

> Yes, I know it's not backwards compatible, but we just went through that 
> argument with log_line_prefix ;-)

I think it's the same argument: neither of these variables are likely to
be touched by application code, only by config file entries; so we need
not feel compelled to provide backwards-compatibility options.

> Actually, if we wanted to go the whole hog with virtual hosting we'd 
> allow per-address port specification, like apache does, but maybe that's 
> something to be left for another day ;-)

Yeah, I don't think that's worth the trouble.  It would open up a bunch
of definitional issues (like which port number do we use as the seed for
the shared memory key), without actually buying much useful functionality.

			regards, tom lane

Sun, 14 Mar 2004 12:45:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: listening addresses 


Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>This slipped off my radar. I have just spent a little while thinking 
>>about it. How about this: we replace tcpip_socket and virtual_host with 
>>a new var called listen_addresses, which can have values of "local", 
>>"all", or a list of addresses? The default would be "local" and -i would 
>>correspond to "all".
>>    
>>
>
>No objection here.  You could also allow "none" (or maybe that falls out
>of the list case by writing an empty list), with the understanding that
>"none" is a useless setting on Windows or any other platform that
>doesn't support Unix sockets.
>  
>

I had thought about "none". I have no strong feelings either way, 
althought you are right that it would be redundant.

On platforms without Unix domain sockets I think we should immediately 
error exit without a valid tcp listening address.

I will try to get this done in the next few weeks - I think it's 
critical for sensible Windows use.

cheers

andrew


Sun, 14 Mar 2004 15:42:39 -0500
Andrew Dunstan <andrew@dunslane.net>
Re: listening addresses
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> How about this: we replace tcpip_socket and virtual_host with 
>>> a new var called listen_addresses, which can have values of "local", 
>>> "all", or a list of addresses? The default would be "local" and -i would 
>>> correspond to "all".
>> 
>> No objection here.  You could also allow "none" (or maybe that falls out
>> of the list case by writing an empty list), with the understanding that
>> "none" is a useless setting on Windows or any other platform that
>> doesn't support Unix sockets.

> I had thought about "none". I have no strong feelings either way, 
> althought you are right that it would be redundant.

Also, "local" would be better spelled "localhost", which would make it
not a special case but just the same as writing a list containing just
that one name.  That leaves only "all" as a special case.  Perhaps you
could write "all" as "*", and thereby not have any special keywords
needed in the variable: it's either "*" or a list of addresses or names.
The advantage of this is you need not worry about collisions of DNS
names with keywords.

			regards, tom lane

Sun, 14 Mar 2004 16:16:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: listening addresses 


Bruce Momjian wrote:

>Andrew Dunstan wrote:
>
>>Also, what is the default connection mode of psql? It should probably be 
>>equivalent to "-h localhost", shouldn't it?
>>    
>>
>
>Now that is something I had not thought of.  Seems we can assume a Win32
>psql can never use unix domain sockets, so defaulting that to localhost
>is a good solution too.
>

The trivial patch below does this (I think). I still don't have an 
available Windows box for testing, so someone who does please verify.

thanks

andrew

Index: src/bin/psql/startup.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
retrieving revision 1.85
diff -c -r1.85 startup.c
*** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
--- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
***************
*** 153,158 ****
--- 153,162 ----
pset.getPassword = false;
#endif

+ #ifndef HAVE_UNIX_SOCKETS
+ options.host = "localhost";
+ #endif
+
parse_psql_options(argc, argv, &options);

if (!pset.popt.topt.fieldSep)





Mon, 15 Mar 2004 05:43:30 -0500
Andrew Dunstan <andrew@dunslane.net>
default psql to localhost on platforms without unix domain sockets

Patch applied, with comment added.  Thanks.

---------------------------------------------------------------------------


Andrew Dunstan wrote:
> 
> 
> Bruce Momjian wrote:
> 
> >Andrew Dunstan wrote:
> >
> >>Also, what is the default connection mode of psql? It should probably be 
> >>equivalent to "-h localhost", shouldn't it?
> >>    
> >>
> >
> >Now that is something I had not thought of.  Seems we can assume a Win32
> >psql can never use unix domain sockets, so defaulting that to localhost
> >is a good solution too.
> >
> 
> The trivial patch below does this (I think). I still don't have an 
> available Windows box for testing, so someone who does please verify.
> 
> thanks
> 
> andrew
> 
> Index: src/bin/psql/startup.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
> retrieving revision 1.85
> diff -c -r1.85 startup.c
> *** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
> --- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
> ***************
> *** 153,158 ****
> --- 153,162 ----
> pset.getPassword = false;
> #endif
> 
> + #ifndef HAVE_UNIX_SOCKETS
> + options.host = "localhost";
> + #endif
> +
> parse_psql_options(argc, argv, &options);
> 
> if (!pset.popt.topt.fieldSep)
> 
> 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 23 Mar 2004 22:10:46 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: default psql to localhost on platforms without unix domain

Should we have used 127.0.0.1 rather than 'localhost' here?

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> 
> 
> Bruce Momjian wrote:
> 
> >Andrew Dunstan wrote:
> >
> >>Also, what is the default connection mode of psql? It should probably be 
> >>equivalent to "-h localhost", shouldn't it?
> >>    
> >>
> >
> >Now that is something I had not thought of.  Seems we can assume a Win32
> >psql can never use unix domain sockets, so defaulting that to localhost
> >is a good solution too.
> >
> 
> The trivial patch below does this (I think). I still don't have an 
> available Windows box for testing, so someone who does please verify.
> 
> thanks
> 
> andrew
> 
> Index: src/bin/psql/startup.c
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/startup.c,v
> retrieving revision 1.85
> diff -c -r1.85 startup.c
> *** src/bin/psql/startup.c 19 Feb 2004 19:40:09 -0000 1.85
> --- src/bin/psql/startup.c 15 Mar 2004 10:37:50 -0000
> ***************
> *** 153,158 ****
> --- 153,162 ----
> pset.getPassword = false;
> #endif
> 
> + #ifndef HAVE_UNIX_SOCKETS
> + options.host = "localhost";
> + #endif
> +
> parse_psql_options(argc, argv, &options);
> 
> if (!pset.popt.topt.fieldSep)
> 
> 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 23 Mar 2004 22:27:19 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: default psql to localhost on platforms without unix domain
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Should we have used 127.0.0.1 rather than 'localhost' here?

No.  Think IPv6.

			regards, tom lane

Tue, 23 Mar 2004 22:42:19 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: default psql to localhost on platforms without unix domain 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Should we have used 127.0.0.1 rather than 'localhost' here?
> 
> No.  Think IPv6.

OK, just asking in case.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 23 Mar 2004 22:48:18 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: default psql to localhost on platforms without unix domain