Another crack at doing a Win32 build under MINGW

(guess) try configuring without readline.

cheers

andrew

Dann Corbit wrote:

U�ytkownik Andrew Dunstan napisa�:

(guess) try configuring without readline.

Or compile readline with your Mingw version, or just replace readline.a
with readline.dll in your lib directory.
All works with readline fine.

Best regards
Rony

I am able to build now, and perform initdb. However, I cannot run the
postmaster. I don't know how far along the port is. What is the
current state of the port to Win32?

dcorbit@DANNFAST /usr/local/pgsql/bin
$ postmaster -D u:/pgdata
LOG: select() failed in postmaster: No such file or directory

dcorbit@DANNFAST /usr/local/pgsql/bin
$ FATAL: could not attach to proper memory at fixed address:
shmget(key=5432001, addr=00E10000) failed: No such file or directory

Dann Corbit wrote:

I am able to build now, and perform initdb. However, I cannot run the
postmaster. I don't know how far along the port is. What is the
current state of the port to Win32?

dcorbit@DANNFAST /usr/local/pgsql/bin
$ postmaster -D u:/pgdata
LOG: select() failed in postmaster: No such file or directory

dcorbit@DANNFAST /usr/local/pgsql/bin
$ FATAL: could not attach to proper memory at fixed address:
shmget(key=5432001, addr=00E10000) failed: No such file or directory

[ email moved to win32 list.]

They have only a few regression tests failing, so we are very far along.

The message you are seeing looks like code that assumes that a child can
map to the same shared memory address as the postmaster. We haven't
seen that fail for anyone before, but it is an assumption we weren't
sure about. Of course this is all a guess.

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

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

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

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

"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

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

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

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

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

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

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

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

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

[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

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

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