Andrew Dunstan <andrew@dunslane.net> writes:
> Honda Shigehiro has diagnosed the longstanding problems with his
> Tru64/Alpha buildfarm member (bear). See below.

> First, it appears that there is a problem with the system getaddrinfo(),
> which configure reports as usable, but turns out not to be. Our current
> configure test checks the return value of getaddrinfo("", "", NULL,
> NULL) but I am wondering if we should test for "localhost" instead of ""
> as the first parameter.

Huh? That's just an AC_TRY_LINK test, we don't actually execute it.
If we did, the test would fail on machines where resolution of "localhost"
is broken, which we already know is a not-so-rare disease ...

I'm not sure that I believe the "getaddrinfo doesn't work" diagnosis
anyway, seeing that bear gets through "make check" okay. Wouldn't that
fail too if there were a problem there?

> Second, it appears that this platform apparently doesn't handle Infinity
> and NaN well. The regression diffs are attached.

On the FPE front, it'd be useful to get a gdb traceback to see where the
SIGFPE is occurring.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>Honda Shigehiro has diagnosed the longstanding problems with his
>>Tru64/Alpha buildfarm member (bear). See below.
>>
>>
>
>
>
>>First, it appears that there is a problem with the system getaddrinfo(),
>>which configure reports as usable, but turns out not to be. Our current
>>configure test checks the return value of getaddrinfo("", "", NULL,
>>NULL) but I am wondering if we should test for "localhost" instead of ""
>>as the first parameter.
>>
>>
>
>Huh? That's just an AC_TRY_LINK test, we don't actually execute it.
>If we did, the test would fail on machines where resolution of "localhost"
>is broken, which we already know is a not-so-rare disease ...
>
>I'm not sure that I believe the "getaddrinfo doesn't work" diagnosis
>anyway, seeing that bear gets through "make check" okay. Wouldn't that
>fail too if there were a problem there?
>
>
>

Now that I look further into it, this machine was working just fine
until we made a change in configure, allegedly to get things right on
Tru64. The first build that went wrong was the one right after
configure.in version 1.450. I see a report from Albert Chin that this
patch worked, but the buildfarm member seems to provide counter-proof.


cheers

andrew

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

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I'm not sure that I believe the "getaddrinfo doesn't work" diagnosis
>> anyway, seeing that bear gets through "make check" okay. Wouldn't that
>> fail too if there were a problem there?

> Now that I look further into it, this machine was working just fine
> until we made a change in configure, allegedly to get things right on
> Tru64. The first build that went wrong was the one right after
> configure.in version 1.450. I see a report from Albert Chin that this
> patch worked, but the buildfarm member seems to provide counter-proof.

Ugh. So probably it depends on just which version of Tru64 you're using
:-(. Maybe earlier versions of Tru64 have a broken getaddrinfo and it's
fixed in later ones? How would we tell the difference?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>> I'm not sure that I believe the "getaddrinfo doesn't work" diagnosis
>>> anyway, seeing that bear gets through "make check" okay. Wouldn't that
>>> fail too if there were a problem there?
>>>
>
>
>> Now that I look further into it, this machine was working just fine
>> until we made a change in configure, allegedly to get things right on
>> Tru64. The first build that went wrong was the one right after
>> configure.in version 1.450. I see a report from Albert Chin that this
>> patch worked, but the buildfarm member seems to provide counter-proof.
>>
>
> Ugh. So probably it depends on just which version of Tru64 you're using
> :-(. Maybe earlier versions of Tru64 have a broken getaddrinfo and it's
> fixed in later ones? How would we tell the difference?
>

I have done some more digging on this. The buildfarm member had a couple
of configuration issues which I have remedied, and which almost
certainly account for the float test errors we saw. However, we still
get an error when we try to start the installed s/w with the default
listen_addresses:

LOG: could not translate host name "localhost", service "5832" to address: servname not supported for ai_socktype

Of course, this won't be seen with "make check", since it starts on Unix
with listen_addresses='', which means we never even look for any sort of
TCP addrinfo.

I found a hint on the web that we should use -D_SOCKADDR_LEN. I tried
this, but got a link failure, complaining about revc and send. This man
page extract explains:

[Tru64 UNIX] The recv() function is identical to the recvfrom() function
with a zero-valued address_len parameter, and to the read() function if no
flags are used. For that reason the recv() function is disabled when
4.4BSD behavior is enabled; that is, when the _SOCKADDR_LEN compile-time
option is defined.

I'd like to know some settings that we can use that will get Tru64
cleanly through the buildfarm set. If noone offers any, I propose that
we revert the getaddrinfo() test in configure and use our own on Tru64
until they do.

cheers

andrew






---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

I wrote:
>
> I have done some more digging on this. The buildfarm member had a
> couple of configuration issues which I have remedied, and which almost
> certainly account for the float test errors we saw. However, we still
> get an error when we try to start the installed s/w with the default
> listen_addresses:
>
> LOG: could not translate host name "localhost", service "5832" to
> address: servname not supported for ai_socktype
>
> Of course, this won't be seen with "make check", since it starts on
> Unix with listen_addresses='', which means we never even look for any
> sort of TCP addrinfo.
>
> I found a hint on the web that we should use -D_SOCKADDR_LEN. I tried
> this, but got a link failure, complaining about revc and send. This
> man page extract explains:
>
> [Tru64 UNIX] The recv() function is identical to the recvfrom()
> function
> with a zero-valued address_len parameter, and to the read() function
> if no
> flags are used. For that reason the recv() function is disabled when
> 4.4BSD behavior is enabled; that is, when the _SOCKADDR_LEN compile-time
> option is defined.
>
> I'd like to know some settings that we can use that will get Tru64
> cleanly through the buildfarm set. If noone offers any, I propose that
> we revert the getaddrinfo() test in configure and use our own on Tru64
> until they do.
>

I have not had any response to this. Is there any objection to my
reverting the configure changes for the head and 8.1 branches? If not I
intend to do that around the end of the week.

cheers

andrew

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

http://archives.postgresql.org

Andrew Dunstan <andrew@dunslane.net> writes:
>> I'd like to know some settings that we can use that will get Tru64
>> cleanly through the buildfarm set. If noone offers any, I propose that
>> we revert the getaddrinfo() test in configure and use our own on Tru64
>> until they do.

> I have not had any response to this. Is there any objection to my
> reverting the configure changes for the head and 8.1 branches?

Presumably, whoever was complaining beforehand will come back ...
but I don't remember who that was.

regards, tom lane

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

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>>>I'd like to know some settings that we can use that will get Tru64
>>>cleanly through the buildfarm set. If noone offers any, I propose that
>>>we revert the getaddrinfo() test in configure and use our own on Tru64
>>>until they do.
>
>
>>I have not had any response to this. Is there any objection to my
>>reverting the configure changes for the head and 8.1 branches?
>
>
> Presumably, whoever was complaining beforehand will come back ...
> but I don't remember who that was.
>
> regards, tom lane
>


i think the issue you are referring to comes from a Solaris report.
some patch levels of solaris have seriously broken getaddrinfo(). in
this case pg_hba.conf cannot be read anymore.
we got a similar report some time ago. we did a simple configure tweak
to make sure that the onboard function is used. it seems to happen only
on some strange patchlevel (god knows which ones).

best regards,

hans


--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster