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

From Sandeep Thakkar
Subject Re: HP-UX 11.31 Itanium2 64bit again
Date
Msg-id CANFyU94V=rAMRKYvTGEjf2vuA+eX+KAk5aVPMci2L=G=oF753Q@mail.gmail.com
Whole thread Raw
In response to Re: HP-UX 11.31 Itanium2 64bit again  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
I'm taking a look.. Results for all branches should be available soon..


On Tue, Mar 11, 2014 at 9:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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



--
Sandeep Thakkar

pgsql-bugs by date:

Previous
From: Rainer Tammer
Date:
Subject: Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1
Next
From: Grégory Giannoni
Date:
Subject: LIMIT causes huge slow down