Re: HP-UX 11.31 Itanium2 64bit again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "H(dot)Merijn Brand" <h(dot)m(dot)brand(at)procura(dot)nl>
Cc: pgsql-bugs(at)postgresql(dot)org, cm(at)enterprisedb(dot)com
Subject: Re: HP-UX 11.31 Itanium2 64bit again
Date: 2014-03-11 15:38:40
Message-ID: 13789.1394552320@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Johnston 2014-03-11 15:47:17 Re: BUG #9519: Allows storing scalar json, but fails when querying
Previous Message martin.klinger 2014-03-11 14:31:55 BUG #9530: Debugg recursion function