"Kirby Bohling (TRSi)" <kbohling@oasis.novia.net> writes:
> If you follow the code from the entry into PQexec, all that way into
> pqWait, and then down into the select call, I noticed that nowhere in the
> path of execution did it check conn->status to see if the status was
> CONNECTION_OK, it only checked to see if the socket non-negative.
Shouldn't matter --- the sock field is set to -1 whenever the connection
is closed. Anyway, CONNECTION_BAD is a higher-level concept; I'm not
sure that pqWait should be looking at it.
> If my guess is correct, the backend has gone away, select can't tell that
> you are never going to be able to read or write on that socket.
Not true, at least not unless you are running atop a broken TCP stack.
A read wait on a socket that's been closed at the other end returns an
immediate EOF indication.
I'm not sure what's causing your problem, but I don't believe you've
identified the correct cause. Have you looked at the postmaster log
to see what the backend thinks is happening?
> typedef struct pg_conn PGConn;
>
> Nice opaque typedef, but no way for me to print the structure in a
> debugger short of printing the raw memory.
Compile libpq with debugging symbols, and the debugger should know what
a PGConn looks like.
regards, tom lane
