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