Vista/IPv6

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

cheers

andrew

On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

Let me pre-emt the discussion by saying that the msvc build does not detect
ipv6 on the build machine (yet). Are you building with msvc or mingw on
this machine?

//Magnus

Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

Something is broken then, because it clearly is turned on, yet the
pg_hba.conf entry is commented out - hence my report. I assume it's
initdb that's doing the check?

Regards, Dave.

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

Let me pre-emt the discussion by saying that the msvc build does not detect
ipv6 on the build machine (yet). Are you building with msvc or mingw on
this machine?

msvc. Grrr.

Eta to fix?

Regards, Dave.

On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote:

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

Let me pre-emt the discussion by saying that the msvc build does not detect
ipv6 on the build machine (yet). Are you building with msvc or mingw on
this machine?

msvc. Grrr.

Eta to fix?

Eh. None, so far :-)
Point being - if you build on a ipv6 enabled machine, will that binary then
work at all on a non-ipv6 machine? Consider binaries distributed by the
installer... Might as well think up the proper fix before we just band-aid
it for the regression tests..

//Magnus

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote:

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page:

This means that the regression tests fail to run, leaving a
postmaster.log full of 'no pg_hba.conf entry for host ::1' errors.
Should we have initdb enable the ::1 pg_hba.conf trust entry by default
on Vista? Any better options?

The default installation has that.

... as long as it's present and turned on on the build machine.

Let me pre-emt the discussion by saying that the msvc build does not detect
ipv6 on the build machine (yet). Are you building with msvc or mingw on
this machine?

msvc. Grrr.

Eta to fix?

Eh. None, so far :-)
Point being - if you build on a ipv6 enabled machine, will that binary then
work at all on a non-ipv6 machine? Consider binaries distributed by the
installer... Might as well think up the proper fix before we just band-aid
it for the regression tests..

Yes, it should.

This was all tested back when we fixed Windows ipv6, around 8.1
timeframe. Look at the source of initdb and you'll see how it works.

cheers

andrew

Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander:

Point being - if you build on a ipv6 enabled machine, will that binary then
work at all on a non-ipv6 machine? Consider binaries distributed by the
installer... Might as well think up the proper fix before we just band-aid
it for the regression tests..

The check is done by initdb (not on the build machine) and it checks if
getaddrinfo("::1", ...) works. If that doesn't work then you don't have IPv6
for all practical purposes. So everything seems to be set up all right.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander:

Point being - if you build on a ipv6 enabled machine, will that binary then
work at all on a non-ipv6 machine? Consider binaries distributed by the
installer... Might as well think up the proper fix before we just band-aid
it for the regression tests..

The check is done by initdb (not on the build machine) and it checks if
getaddrinfo("::1", ...) works. If that doesn't work then you don't have IPv6
for all practical purposes. So everything seems to be set up all right.

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

cheers

andrew

#ifdef HAVE_IPV6

/*
* Probe to see if there is really any platform support for IPv6, and
* comment out the relevant pg_hba line if not. This avoids runtime
* warnings if getaddrinfo doesn't actually cope with IPv6.
Particularly
* useful on Windows, where executables built on a machine with IPv6 may
* have to run on a machine without.
*/
{
struct addrinfo *gai_result;
struct addrinfo hints;
int err = 0;

#ifdef WIN32
/* need to call WSAStartup before calling getaddrinfo */
WSADATA wsaData;

err = WSAStartup(MAKEWORD(2, 2), &wsaData);
#endif

/* for best results, this code should match parse_hba() */
hints.ai_flags = AI_NUMERICHOST;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = 0;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;

if (err != 0 ||
getaddrinfo("::1", NULL, &hints, &gai_result) != 0)
conflines = replace_token(conflines,
"host all all ::1",
"#host all all
::1");
}
#else /* !HAVE_IPV6 */
/* If we didn't compile IPV6 support at all, always comment it out */
conflines = replace_token(conflines,
"host all all ::1",
"#host all all ::1");
#endif /* HAVE_IPV6 */

Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan:

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

Yeah, the problem is that the msvc build has no intelligence to detect the
IPv6 APIs to define HAVE_IPV6. So that needs to be developed.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan:

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

Yeah, the problem is that the msvc build has no intelligence to detect the
IPv6 APIs to define HAVE_IPV6. So that needs to be developed.

The configure test just looks for a definition of struct sockaddr_in6.
Taking a quick look It seems to me like this is unconditionally there in
the MSVC WS2tcpip.h , so maybe we should just force it for MSVC.

cheers

andrew

On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan:

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

Yeah, the problem is that the msvc build has no intelligence to detect the
IPv6 APIs to define HAVE_IPV6. So that needs to be developed.

The configure test just looks for a definition of struct sockaddr_in6.
Taking a quick look It seems to me like this is unconditionally there in
the MSVC WS2tcpip.h , so maybe we should just force it for MSVC.

That was my question. I just built with ipv6 enabled using my msvc build on
my primary machine which does *not* have ipv6, and it still passes
regression tests fine.

Given that we have a runtime check, is there any reason at all not to
enable ipv6 on all builds on msvc?

(FWIW, it's been in the platform SDK at least since Windows 2000)

//Magnus

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan:

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

Yeah, the problem is that the msvc build has no intelligence to detect the
IPv6 APIs to define HAVE_IPV6. So that needs to be developed.

The configure test just looks for a definition of struct sockaddr_in6.
Taking a quick look It seems to me like this is unconditionally there in
the MSVC WS2tcpip.h , so maybe we should just force it for MSVC.

That was my question. I just built with ipv6 enabled using my msvc build on
my primary machine which does *not* have ipv6, and it still passes
regression tests fine.

Given that we have a runtime check, is there any reason at all not to
enable ipv6 on all builds on msvc?

(FWIW, it's been in the platform SDK at least since Windows 2000)

If we could use configure for MSVC this would have Just Happened (tm). I
wonder how many other little bits we miss out on?

Anyway, the obvious fix seems to be to add a line to
src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h

cheers

andrew

On Wed, Apr 11, 2007 at 02:24:08PM -0400, Andrew Dunstan wrote:

Magnus Hagander wrote:

On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote:

Peter Eisentraut wrote:

Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan:

There is a configure time and a runtime check. The code is below - note
the first #ifdef.

Yeah, the problem is that the msvc build has no intelligence to detect
the IPv6 APIs to define HAVE_IPV6. So that needs to be developed.

The configure test just looks for a definition of struct sockaddr_in6.
Taking a quick look It seems to me like this is unconditionally there in
the MSVC WS2tcpip.h , so maybe we should just force it for MSVC.

That was my question. I just built with ipv6 enabled using my msvc build on
my primary machine which does *not* have ipv6, and it still passes
regression tests fine.

Given that we have a runtime check, is there any reason at all not to
enable ipv6 on all builds on msvc?

(FWIW, it's been in the platform SDK at least since Windows 2000)

If we could use configure for MSVC this would have Just Happened (tm). I
wonder how many other little bits we miss out on?

Well, if you can make that happen, certainly that'd be nice...
(FWIW, I had ipv6 on my list of things to make happen, but I didn't realise
it would cause this issue on a machine with ipv6 on it, since I don't have
one)

Anyway, the obvious fix seems to be to add a line to
src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h

Won't work, that hits both msvc and mingw. (assuming you maen
pg_config.h.win32, since pg_config.h is a generated file)

The proper fix is to put it in the msvc build sys, where it writes
pg_config.h :-) It also needs a new lib for initdb. I have a patch
for it, and it works here, I'm just asking if it's safe to enable it or if
it may cause runtmie problems on platforms without ipv6.

//Magnus

Magnus Hagander wrote:

Anyway, the obvious fix seems to be to add a line to
src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h

Won't work, that hits both msvc and mingw. (assuming you maen
pg_config.h.win32, since pg_config.h is a generated file)

The proper fix is to put it in the msvc build sys, where it writes
pg_config.h :-)

Is that not what I suggested?

It also needs a new lib for initdb. I have a patch
for it, and it works here, I'm just asking if it's safe to enable it or if
it may cause runtmie problems on platforms without ipv6.

Which new lib? That seems odd since what we do on MinGW does work.

cheers

andrew

Andrew Dunstan wrote:

Magnus Hagander wrote:

Anyway, the obvious fix seems to be to add a line to
src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h

Won't work, that hits both msvc and mingw. (assuming you maen
pg_config.h.win32, since pg_config.h is a generated file)

The proper fix is to put it in the msvc build sys, where it writes
pg_config.h :-)

Is that not what I suggested?

I thought you meant put it in the actual .h file that is used to
generate pg_config.h from. Apologies for my misunderstanding.

It also needs a new lib for initdb. I have a patch
for it, and it works here, I'm just asking if it's safe to enable it
or if
it may cause runtmie problems on platforms without ipv6.

Which new lib? That seems odd since what we do on MinGW does work.

The winsock libs. Our mingw build links them explicitly to all binaries,
the msvc build only links it to the ones that actually need it. And with
ipv6 support, initdb suddenly needs it.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

The proper fix is to put it in the msvc build sys, where it writes
pg_config.h :-) It also needs a new lib for initdb. I have a patch
for it, and it works here, I'm just asking if it's safe to enable it or if
it may cause runtmie problems on platforms without ipv6.

Try it and find out ;-) ... that's what we have a buildfarm for.

regards, tom lane

Magnus Hagander wrote:

(FWIW, I had ipv6 on my list of things to make happen, but I didn't
realise it would cause this issue on a machine with ipv6 on it, since
I don't have one)

The IPv6 support is finely tuned to deal with all kinds of combinations
of API support, library support, and kernel support, or lack thereof,
on the build system and on the host system. I suggest that you just
use the logic that we have or emulate it, respectively. If it doesn't
work, we will find out soon enough.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

The proper fix is to put it in the msvc build sys, where it writes
pg_config.h :-) It also needs a new lib for initdb. I have a patch
for it, and it works here, I'm just asking if it's safe to enable it or if
it may cause runtmie problems on platforms without ipv6.

Try it and find out ;-) ... that's what we have a buildfarm for.

Well, on the buildfarm the build host is the test host, so that doesn't
quite take care of Magnus' concern.

But that said, I do think it will probably Just Work - we did a lot of
work during 8.1 to make sure it would, and I see no reason yet to think
that work won't apply.

cheers

andrew

On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote:

If we could use configure for MSVC this would have Just Happened (tm). I
wonder how many other little bits we miss out on?

CMake anyone?

wt
--
Warren Turkal (w00t)

On Wed, Apr 11, 2007 at 11:06:12PM -0600, Warren Turkal wrote:

On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote:

If we could use configure for MSVC this would have Just Happened (tm). I
wonder how many other little bits we miss out on?

CMake anyone?

IIRC, cmake is a replacement for make, not for configure. Or did I miss
something?

And it would require rewriting all the unix makefiles in cmake format,
and it was one of the major requirements for this undertaking that this
would not be required.

//Magnus

On Thu, Apr 12, 2007 at 12:24:58AM +0200, Peter Eisentraut wrote:

Magnus Hagander wrote:

(FWIW, I had ipv6 on my list of things to make happen, but I didn't
realise it would cause this issue on a machine with ipv6 on it, since
I don't have one)

The IPv6 support is finely tuned to deal with all kinds of combinations
of API support, library support, and kernel support, or lack thereof,
on the build system and on the host system. I suggest that you just
use the logic that we have or emulate it, respectively. If it doesn't
work, we will find out soon enough.

The point is still what happens when you distribute a binary built on a
system with ipv6 to a system that doesn't have it.

Anyway. It seems reasonably safe, since I can build with ipv6 on my machine
without the ipv6 driver, and it still works. Dave will have to test if it
actually works on a machine that *has* ipv6 :-)

So. Changes applied.

//Magnus

Magnus Hagander wrote:

On Thu, Apr 12, 2007 at 12:24:58AM +0200, Peter Eisentraut wrote:

Magnus Hagander wrote:

(FWIW, I had ipv6 on my list of things to make happen, but I didn't
realise it would cause this issue on a machine with ipv6 on it, since
I don't have one)

The IPv6 support is finely tuned to deal with all kinds of combinations
of API support, library support, and kernel support, or lack thereof,
on the build system and on the host system. I suggest that you just
use the logic that we have or emulate it, respectively. If it doesn't
work, we will find out soon enough.

The point is still what happens when you distribute a binary built on a
system with ipv6 to a system that doesn't have it.

Anyway. It seems reasonably safe, since I can build with ipv6 on my machine
without the ipv6 driver, and it still works. Dave will have to test if it
actually works on a machine that *has* ipv6 :-)

So. Changes applied.

Thanks - I can test a Vista build on a non-ipv6 machine when I'm back in
the office - possibly tomorrow, certainly Monday.

Regards, Dave

Hi.

From: "Dave Page" <dpage@postgresql.org>

So. Changes applied.

Umm, I think that you should correspond here.
It seems to have been left. I remember it.

src/include/pg_config.h.win32
/* Define to 1 if you have support for IPv6. */
// #define HAVE_IPV6 1

What do you think?

Regards,
Hiroshi Saito

Am Donnerstag, 12. April 2007 09:04 schrieb Magnus Hagander:

The point is still what happens when you distribute a binary built on a
system with ipv6 to a system that doesn't have it.

I think the problem is that you appear to have an ambiguous and overly coarse
definition of a "system with ipv6".

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Donnerstag, 12. April 2007 08:56 schrieb Magnus Hagander:

IIRC, cmake is a replacement for make, not for configure. Or did I miss
something?

CMake might be considered a replacement for Automake.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Thu, Apr 12, 2007 at 10:58:26AM +0200, Peter Eisentraut wrote:

Am Donnerstag, 12. April 2007 09:04 schrieb Magnus Hagander:

The point is still what happens when you distribute a binary built on a
system with ipv6 to a system that doesn't have it.

I think the problem is that you appear to have an ambiguous and overly coarse
definition of a "system with ipv6".

Possibly :-) I just want to make sure it doesn't break for our end users,
no matter what the definition is.

//Magnus

On Thu, Apr 12, 2007 at 05:14:06PM +0900, Hiroshi Saito wrote:

Hi.

From: "Dave Page" <dpage@postgresql.org>

So. Changes applied.

Umm, I think that you should correspond here.
It seems to have been left. I remember it.

src/include/pg_config.h.win32
/* Define to 1 if you have support for IPv6. */
// #define HAVE_IPV6 1

What do you think?

It's defined ni the msvc build script, see
http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php

//Magnus

src/include/pg_config.h.win32
/* Define to 1 if you have support for IPv6. */
// #define HAVE_IPV6 1

What do you think?

It's defined ni the msvc build script, see
http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php

It is a meaning with win32.mak. Then, It is the outside of the msvc tool.

Regards,
Hiroshi Saito

On Thursday 12 April 2007 00:56, you wrote:

IIRC, cmake is a replacement for make, not for configure. Or did I miss
something?

CMake also has configure functionality.

And it would require rewriting all the unix makefiles in cmake format,
and it was one of the major requirements for this undertaking that this
would not be required.

The CMakeLists.txt files can coexist with the current Makefiles. You could
just do out of tree builds to keep from overwriting the original Makefiles
during the generation. Of course, generating MSVC project files wouldn't
overwrite the Makefiles in any case.

wt
--
Warren Turkal (w00t)

On Fri, Apr 13, 2007 at 12:44:41AM -0600, Warren Turkal wrote:

On Thursday 12 April 2007 00:56, you wrote:

IIRC, cmake is a replacement for make, not for configure. Or did I miss
something?

CMake also has configure functionality.

And it would require rewriting all the unix makefiles in cmake format,
and it was one of the major requirements for this undertaking that this
would not be required.

The CMakeLists.txt files can coexist with the current Makefiles. You could
just do out of tree builds to keep from overwriting the original Makefiles
during the generation. Of course, generating MSVC project files wouldn't
overwrite the Makefiles in any case.

That would mean maintainig two sets of build files. That's never going to
work. The only option if we were to go with that is, IMHO, to move
*everything* over to it. And I don't think you'll get a lot of people
supporting that ;)

//Magnus

On Thu, Apr 12, 2007 at 08:46:09PM +0900, Hiroshi Saito wrote:

src/include/pg_config.h.win32
/* Define to 1 if you have support for IPv6. */
// #define HAVE_IPV6 1

What do you think?

It's defined ni the msvc build script, see
http://archives.postgresql.org/pgsql-committers/2007-04/msg00148.php

It is a meaning with win32.mak. Then, It is the outside of the msvc tool.

I see.

But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows
2000 and the windows IPV6 support.

Can you verify that it works if you manually add this #define and build
with MSVC6?

//Magnus

Hi.

From: "Magnus Hagander" <magnus@hagander.net>

I see.

But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows
2000 and the windows IPV6 support.

Can you verify that it works if you manually add this #define and build
with MSVC6?

I don't have IPV6 test environment recently.... However, It has the compile environment
of VC6, and it is finished finely. Then, win32.mak is not the thing of only VC6.
And VC 7.1, VC8, and they will be used. It should be then supported IPV6 at least.
What confirmed #DEFINE of IPV6 and built it by VC6 has passed the test of IPV4 further
again. Therefore, you should make it effective.

Regards,
Hiroshi Saito

Hiroshi Saito wrote:

Hi.

From: "Magnus Hagander" <magnus@hagander.net>

I see.

But - does it work when build with MSVC6? IIRC, MSVC6 pre-dates windows
2000 and the windows IPV6 support.

Can you verify that it works if you manually add this #define and build
with MSVC6?

I don't have IPV6 test environment recently.... However, It has the
compile environment of VC6, and it is finished finely. Then, win32.mak
is not the thing of only VC6. And VC 7.1, VC8, and they will be used. It
should be then supported IPV6 at least.
What confirmed #DEFINE of IPV6 and built it by VC6 has passed the test
of IPV4 further again. Therefore, you should make it effective.

I have applied a change for this.

//Magnus