Skip site navigation (1) Skip section navigation (2)

Re: [Fwd: DBD::Pg on HP-UX 11.31 64bit]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, "H(dot)Merijn Brand" <h(dot)m(dot)brand(at)xs4all(dot)nl>
Subject: Re: [Fwd: DBD::Pg on HP-UX 11.31 64bit]
Date: 2010-12-14 20:16:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> FW
> From: H.Merijn Brand <h(dot)m(dot)brand(at)xs4all(dot)nl>
> I have postgres running on most my HP-UX varieties, ranging from HP-UX
> 10.20/32bit through 11.31/64bit. It works fine everywhere, except on
> HP-UX 11.31-ipf in 64bit mode. Note that this is Itanium architecture.

> postgres' own test suite passes, but all connects fail with DBD::Pg.

That's pretty odd.  What seems to be failing here:

> This is perl, v5.10.1 (*) built for IA64.ARCHREV_0-LP64
> getsockopt (3, SOL_SOCKET, SO_ERROR, 0x9fffffffffffdb84, 0x9fffffffffffdb98)               ERR#22 EINVAL

is this bit of code in libpq:

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

It's not clear at all how that would fail in the Perl environment if it
works standalone.  I could believe getting EINVAL if we had determined
the wrong datatype for ACCEPT_TYPE_ARG3, but that ought to fail
standalone too, I should think.  Anyway it would be worth checking what
configure identified as ACCEPT_TYPE_ARG3 and comparing that to the docs
for getsockopt.

Meanwhile, this one:

> This is perl 5, version 12, subversion 2 (v5.12.2) built for IA64.ARCHREV_0-LP64-ld
>   Received signal 4, SIGILL, in user mode, [SIG_DFL], partial siginfo
>     Siginfo: si_code: ILL_ILLOPC, faulting address: 0x60000000000ab620, si_errno: 0
>      PC: 00000001000000a0.0

seems like it's just a flat-out library incompatibility --- it looks to
me like it's probably failing immediately upon passing control to libpq.
I'm wondering about issues like word width and endianness.  IA64 can do
either endianness IIRC, so maybe your toolchain is confused about which
it should use?

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Robert HaasDate: 2010-12-14 20:40:23
Subject: Re: Problems with max_connections parameter
Previous:From: Ng, StanDate: 2010-12-14 20:07:55
Subject: Re: index corruption on composite primary key indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group