On Tuesday 01 May 2007 2:23 pm, Tom Lane wrote: > 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. It is indeed a local connection using PGHOST=`hostname`. That name maps to one of the external NIC IPs, not to the normal 127.0.0.1 loopback address. For context, I've seen this a number of times over the past couple years, from pgsql 7.3.x to 8.1.x, HPUX 11.00 to 11.23, 32-bit-only and 32/64 Itaniums, always via a local connection using `hostname` mapping to an external NIC. What it is about the reboots that triggers this remains a mystery. Ed
