Re: HP-UX 11.31 Itanium2 64bit again

From: Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "H(dot)Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>, CM Team <cm(at)enterprisedb(dot)com>
Subject: Re: HP-UX 11.31 Itanium2 64bit again
Date: 2014-03-12 09:16:57
Message-ID: CANFyU94V=rAMRKYvTGEjf2vuA+eX+KAk5aVPMci2L=G=oF753Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "H.Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message uehara.kazuki 2014-03-12 09:37:53 BUG #9541: Result of TRIM function has changed
Previous Message Rainer Tammer 2014-03-12 08:06:16 Re: Problem with PostgreSQL 9.2.7 and make check on AIX 7.1