"Ed L." <pgsql@bluepolka.net> writes:
> Attached is a small tar.gz file containing a short perl DBI
> connection script that repeatedly demonstrates this problem.
> There are also two log files containing tusc output (an HP
> syscall trace utility), one for the 32-bit run (which works) and
> another for the 64-bit run (which fails). I haven't made much
> sense of it yet, so any help deciphering is appreciated.
Well, it's going wrong here:
socket(AF_INET, SOCK_STREAM, 0) .......................... = 4
setsockopt(4, 0x6, TCP_NODELAY, 0x9fffffffffffe210, 4) ... = 0
fcntl(4, F_SETFL, 65536) ................................. = 0
fcntl(4, F_SETFD, 1) ..................................... = 0
connect(4, 0x6000000000416ea0, 16) ....................... = 0
getsockopt(4, SOL_SOCKET, SO_ERROR, 0x9fffffffffffe32c, 0x9fffffffffffe338) = 0
close(4) ................................................. = 0
The close() indicates we're into the failure path, so evidently the
getsockopt returned a failure indication (though it's hard to tell what
--- strerror() isn't providing anything useful). What strikes me as odd
about this is that the connect() really should have returned EINPROGRESS
or some other failure code, because we're doing it in nonblock mode.
A zero return implies that the connection is already made, which it
shouldn't be if you're connecting to some other machine (if this is a
local connection then maybe it's sane, but I don't see that here when
testing loopback TCP connections). So I wonder if connect() is blowing
it here and claiming the connection is ready when it's not quite yet.
Another possibility is that getsockopt() is returning bad data, which
smells a bit more like the sort of thing that might go wrong in 64 vs
32 bit mode.
You might want to adjust connectFailureMessage() in fe-connect.c to
print the actual numeric value of "errorno" along with its strerror
translation ... that might give a bit more hint.
regards, tom lane