Re: HP-UX 11.31 Itanium2 64bit again - Mailing list pgsql-bugs

From Tom Lane
Subject Re: HP-UX 11.31 Itanium2 64bit again
Date
Msg-id 13789.1394552320@sss.pgh.pa.us
Whole thread Raw
In response to HP-UX 11.31 Itanium2 64bit again  ("H.Merijn Brand" <h.m.brand@procura.nl>)
Responses Re: HP-UX 11.31 Itanium2 64bit again  ("H.Merijn Brand" <h.m.brand@procura.nl>)
Re: HP-UX 11.31 Itanium2 64bit again  ("H.Merijn Brand" <h.m.brand@procura.nl>)
Re: HP-UX 11.31 Itanium2 64bit again  (Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>)
List pgsql-bugs
"H.Merijn Brand" <h.m.brand@procura.nl> writes:
> After the installation, DBD::Pg is able to link against libpq.so.5, but
> just as in 2010/2011, it is not able to make any connection due to some
> socket incompatabilities:

> $ perl -MDBI -wE'DBI->connect ("dbi:Pg:")'
> DBI connect('','',...) failed: could not get socket error status: Invalid argument at -e line 1.

> The docs state that  HP-UX is one of the platforms postgresql is tested
> on, but is it ever tested beyond the product itself? Is there anyone to
> guide me in making this work?

PG is tested on approximately that configuration, or was till recently:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=anole&br=HEAD
(Doesn't look like buildfarm member anole has run on HEAD in a couple
of months --- EDB folk, can you unwedge that?)  We don't test Perl
compatibility however.

Assuming that that error is originating in PG and not somewhere in DBI
or Perl, it must be coming from this bit in fe-connect.c:

                if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
                               (char *) &optval, &optlen) == -1)
                {
                    appendPQExpBuffer(&conn->errorMessage,
                    libpq_gettext("could not get socket error status: %s\n"),
                            SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
                    goto error_return;
                }

which makes me wonder if you're hitting some form of the problem described
here:
http://curl.haxx.se/mail/lib-2009-04/0287.html

We normally avoid that problem by defining _XOPEN_SOURCE_EXTENDED
(see src/template/hpux, though you should check your build log to
make sure that symbol actually got passed to cc).  I wonder though
if the Perl environment is somehow causing the other getsockopt
prototype to be called.  Are you *sure* it's a 64-bit Perl build?
Was Perl itself built with _XOPEN_SOURCE_EXTENDED?

> I am now stuck to postgresql-8.4.5 which is the last release I was able
> to build to a state that worked with perl.

AFAIK our code in this area has been about the same since well before 8.4,
so maybe what you're hitting is something else.  But that's the only lead
I have on the basis of the offered evidence.

BTW, googling also turned up your old message
http://www.postgresql.org/message-id/20101216174803.20b2b6db@pc09.procura.nl
in which you claim to have changed the platform #define's around.  That
may not have been such a great idea.  We expect getsockopt to use the
same last argument type as accept() does, and if I've got all the details
straight, you need _XOPEN_SOURCE_EXTENDED to make that true on HPUX.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "H.Merijn Brand"
Date:
Subject: HP-UX 11.31 Itanium2 64bit again
Next
From: David Johnston
Date:
Subject: Re: BUG #9519: Allows storing scalar json, but fails when querying